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An object-focused workflow system for processing a 
receivcdpbjec t in accordance with a declarative workflow 
specification. The specification includes modules and 
attributes, where module execution results in the evaluation 
of attributes, and may include the initiation of a side -effect 
action performed b y an external component . Whether mod- 
ules are to be executed for a particular received obj ect is 
determined by associated enabling conditions. Attributes 
may be evaluated in accordance witli computation mlcs and 
a combining policy, where the computation rules specify 
how values are to be contributed to an attribute, and the 
combining policy indicates how those contributed values are 
combined in order to assign a value to the attribute. Tasks in 
the workflow system may be executed eagerly in order to 
improve the performance of the workflow system. The eager 
evaluation of tasks includes the determination of whether 
such tasks are eligible for eager evaluation, and whether the 
tasks are unncedcd or necessary for the processing of the 
received event. Workflows which satisfy described design 
properties allow for improved algorithms for the determi- 
nation of the whether tasks are eligible, eager, and/or nec- 
essary. A graphical user interface is provided for displaying 
a representation of the evaluation status of the modules and 
attributes during workflow execution. 
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FIG. 3 
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FIG, 4 



1 


Module: identify_caller 






2 


Submodule of: routing_to_skill 




3 


Input attributes: 


ANI : 9digits 




4' 


Output attributes: 


home.phone : 


Qdigits 


5 




account_number : ISdigits 


6 




cust_rec : tuple (name: string, 


7 






address: string, 


8 






card_color: ("platinum", 


9 






"gold", "green"), 


10 






hotes_promos? : boolean, 


11 






estimated_income_bracket : 


12 






("0-10K", ">10K-20K" 

">100K-150K", ">150"), 


13 






U 






last_sent_bonus_check:date) 


15 


Enabling condition: 


true 


16 


Type: flowchart 




17 


Computation: See Fig. 3 




18 


Side-effect: yes 






19 


Side Effect function: 


(IVR Dip) 
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FIG. 6 



1 Module: info_abouLcustomer 

2 Submodule of: routing. to_skill 

3 Input attributes: account.number 

4 cusl_rec 

5 Output attributes: cust_ value : [\J0] 

6 frustration_score : [1..10] 

7 late.poyments.score : [I. .10] 

8 recent_purchases :list(tuple( date : date, 

9 item : ZOdigit, 

10 qty : int, 

11 amount: $value )) 

12 marketina vs.collectlons : {"market", 

13 "collect'f 

15 Enabling condition: VAL(occount_number) 

16 Type: declarotive 

17 Side-effect: no 



FIG, 7 



1 


Module: ln(o_from_web 




2 


Submodule of: routing_to_skill 


3 


Input attributes: 


ANI 


4 


home_phone 


5 




accounLnumber 


6 


Output attributes: 


web.destinatlons : list(tuple(regions: set of 


7 




|"Australia","Asla",... 


8 




"NAmerico-US". "US"!, 


9 




ltlnerary:web_form_content, 


10 




dote_last_modified : date )) 


11 


Enabling condition: 


web_db_load < 95% or not VAL(account_number) 


12 


Type: 


foreign 


13 


Computatjon: 


geLweb_data(ANI, home_phone, accounLnumber) 


14 


Side-effect: 


no 
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FIG. 8 



1 


Module: promo_selection 


2 


Submodule of: routing_to_sl<ill 


3 


Input attributes: 


ANI 


4 


DNIS 


5 




account_number 


6 




cust_rec 


7 




cust_ value 


8 




recent_purchases 


9 




frustration_score 


10 




late_payments_score 


11 




web_destinations 


12 


Output attributes: 


promo_hiLlist : list ( promo_message ) 


13 


Enabling condition: 


cust_rec.hates_promos? = false 


14 


Type: 


foreign 


15 


Computation: 


geLpromo_hit_list(ANI, DNIS, account_number, 


16 




cust_rec, cust_value, recent_purc hoses, 


17 




account_status, frustration.score, 


18 




late_payments_score, web_destinations) 


19 


Side-effect: 


no 
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FIG, 10 



1 Module: routing_decisions 


2 


Submodule of: routing_to_skill 


3 


Input attributes: 


ANI 


4 


ONIS 


5 




account_number 


6 




cusi_rec 


7 




cust_ value 


8 




recent_purchases 


9 




frustration_score 


10 




late_pQyments_score 


11 




web_destinations 


12 


Output attributes: 


calLpriority : [1..4] \\corresponds to "low", 


13 




"med", "high", "top" 


U 




skill : j"norm_tier_dom", "norm_tier_intl", 


15 




"australia_promo", "high_tier", 


16 




collections"! 


17 




on_queue_promo : message_identifier 


18 




screen_pop_list : list ( screen_entry ) 


19 


Enabling condition: 


true 


20 


Type: 


declarative 


21 


Side-effect: 


yes 
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FIG. 11 



1 Module: calculate.wrap.up 

2 Submodule of: rouling_to_skill 

3 Input attributes: Ani 

4 dnis 

5 Web_DB_Load 

6 Promos.OLThe.Doy 

7 Cust.Rec 

8 Home_Phone 

9 Account_Number 

10 Cust_ Value 

11 Frustrotion.Score 

1 2 Late_Payments_Score 

13 RecenLPurchases 

1 4 Marketina_VS_Collections 

15 Web.Destinations 

16 CalLPriority 

17 Skill 

18 OruQueue.Promo 

19 Screen_Pop_List 

20 Promo.HitlList 

21 Output attributes: wrap.up : set ( tuple ( otLname: string, 

22 value: string )) 

23 Enabling condition: true 

24 Type: decision 

25 ComputaUon: 

26 Rules: if true then wrap_up <- (att_name: "DNIS", 

27 value : convert-to-string (DNIS)) 

28 if true then wrap_up <- (att_nanne: 'W\ 

29 value: convert-to-string (ANI)) 

30 . if true then wrap.up <- (att.name: "skill", 

31 value: skill) 

32 if web_destinations not empty then wrop^up <- 

33 (att.name: \"web_destinations*', 

34 value: (convert-to-string 

35 (web.destinotions)) 

36 if cust_rec.card_ color = "gold" <- 

37 (att_name:"frustration_score", 

38 value: convert-to-string 

39 (frustroUon.score)) 

40 Combining policy: wrop-up-cp //use contributions of oil 

41 rules with true condition 

42 Side-effect: yes 

43 Side-effect function: write_into_archive ( wrap.up ) 
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FIG, 12 



1 

1 


Module: get_recent_contacts_for_thls_customer 


2 


Submodule of: info_about_customer 


3 


Input attributes: 


account_number 


4 


Output attributes: 


recent_contacts : list ( tuple ( date: date, 


C 
J 




event: event_type, 


6 




delay_during_contact: int, 


7 




\\ minutes 


8 




delay_before_shipmenl: int 


9 




\\ days 


10 




amount: $value ) ) 


11 


Enabling condition: 


true 


12 


Type: 


foreign 


13 


Computation: 


using recent_contacts_db 


14 




select date,event,amount 


15 




from contacLdb 


16 




where accLnum = account_number 


17 


Side-effect: 


no 
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FIQ. 13 

1 Module: get_recenLpurchases_for_this_customer 

2 Submodule of: info_about_customer 

3 Input attributes: account_number 

4 Output attributes: recenLpurchases : list ( tuple ( date: dote, 

5 item : 20digit, 

6 qty : int, 

7 omount : $volue ) ) 

8 Enabling condition: true 

9 Type: foreign 

10 Computation: using purchase.db 

1 1 select date,item,qty,amount 

12 from purchases 

13 where acct_num = account_number 

14 Side-effect: no 
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FIG, 14 



1 


Module: get_account_history_for_this_customer 


2 


oUDmOQUic or. 


iriTo_aDoui_cusiomer 


3 


inpui aiiriDuies. 


accouni_nLimDer 


4- 


Output attributes: 


QccounLhistory ; tuple ( overdue amount: 


5 




ivalue. 


6 




number_days_overdue: 


7 




int, 


8 




liistory: list ( tuple ( 


9 




date: date, 


10 




item : 20dlgit, 


11 




amount : lvalue ] ) ) 


12 


Enabling condition 


: true 


13 


Type: 


foreign 


14 


Computation: 


using account_liistory_db 


15 




select over_amt, num_days,history 


16 




from account_history 


17 




where acct_num = account_number 


18 


Side-effect: 


no 
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FIG. 15 



1 Module: calculat8_frustration_score 



2 Submodule of: info_abouLcustomer 

5 Input attributes: recent_contacts 

4 Output attributes: frustration_score ; [1..10] 

5 Enabling condition: VAL(recent_contacts) 

6 Type: decision 

7 Computation: 

8 Rules: if recent_contacts|1 defined then 

9 frustration_score <- 

10 jvalue/50) ♦ 

11 [(delay_during_contact/2) + 

12 max(0,delay_before_shipment - 

13 10)/3] 

14 if recenLcontacts|2 defined then 

15 frustration_score <- 

16 jvalue/100) ♦ 

17 [{delav durin9_contact/2) + 

18 max (o,delay„before_shipment - 

19 10)/3] 
20 

21 Combining policy: frustration-score-cp //add contributions 

22 of true rules and 

23 round up, to max 

24 of 10 
25 

26 Side-effect: no 
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FIG. 16 



1 Module: colculate_neLprofiLscore 

2 Submodule of: info_about_customer 

3 Input attributes: recent_contacts, 

4 recent_purchases, 

5 occount_history, 

6 cust_rec 

7 Output ottributes: net_profiLscore 

8 Enobling condition: recenLpurchases#1.date<=now-60 

9 Type: decision 

10 Computation: 

11 Rules: if recent_purchases not empty then 

12 net_profit_ score <- 

13 10% • sum (recent_purchases#i.amount 

14 where recenCpurchasesfi.date > now - 

15 60) 

16 if recent_contacls hot empty then 

17 neLprofiLscore <- 

18 "( 5 * count { recenLcontacts#i 

19 where recent_contacts#i.type = 

20 "complaint")) 

21 if account. history.overdue_amount > 0 

22 then net_profit_score <- 

23 - account_history.overdue_amount ♦ 

24 account_history.number_days_overdue / 30 

25 if cust_rec.card_color = "platinum" then 

26 net_profit_score <- 100 

27 if cusLrec.cord_color = "gold" then 

28 net_profit_score <- 50 

29 if cust.rec.card_color = "green" then 

30 net_profit_score <- 10 

31 if DISABLED(cust_rec) then 

32 net_profit_score <- 20 

33 Combining policy: net-profit-score-cp //add contributions 

34 of rules with true 

35 conditions 
36 

37 Side-effect: no 
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FIG. 17 



1 


Module: calculate_late_payment_ 


.score 


2 


Submodule of: info_about_customer 


3 


Input attributes: account_history 


4 


Output attributes: late_payment_score 




Enabling condition: YAL(account_history) 


6 


Tvoe: decision 




7 


Computation: 




8 


Rules: 


if cust_rec.card_color = "plaUnum" then 


9 




late_payments_score <- 


10 




(occounLhistory.overdue.amount 


11 




number_of_days_overdue)/l 00 


12 




if cust_r€c.card_color = "gold" then 


13 




late_payments_score <- 


14 




(account_history.overdue_amount * 


15 




number.of days_overdue)/50 


16 




if cusLrec.card.coior = "green" then 


17 




late_payments_score <- 


18 




(accounLhistory.overdue_amount ♦ 


19 




number.of days_overdue)/lO 


20 


Combining policy: 


lote-payment-score-cp //rule with true 


21 


condition wins; 


22 




default is 0 


23 






24 


Side-effect: no 
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1 Module: calculate.cusLvalue 

2 Submodule of: info_abouLcustomer 



3 Input attributes: 

4 

5 



net_profit_score, 

late_payments_score, 

cust_rec 



6 Output attributes: cust_volue 

7 Enabling condition: true 

8 Type: decision 



9 Computation: 

10 Rules: If VAL(net_profit_score) tlien cust_volue <- 

11 (1 - 1/net_profit_score) ♦ 75 

12 if cust_rec.card_color = "platinum" ttien 

13 cust_value <- 20 

14 if cust_rec.card_color = "gold" then cust_ value 

15 <- 10 

16 if cust_rec.card_color = "green" then 

17 cust_volue <- 5 

18 if VAL (frustration.score) then cust_ value <- 

19 5*frustration_score 

20 Combining policy: calculate-cust-vol-cp //Add values of true 

21 rules and round up, to 

22 max of 100, default is 

23 0 
24 

25 Side-effect: no 
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FIG, 19 



1 Module: calculate. marl(eting_vs_collections 



2 


Submodule of: info_about_customer 


3 


Input attributes: 


cust_value, 


4 




late_payments_score 


5 


Output attributes: 


marketing_vs_collections 


a 
0 


Enabling condition: 


late_payments_score > 0 


7 


Type: decision 


8 


Computation: 


if late_payments_score > f(cust_value) then 


g 


Rules: 


10 




marketing_vs_collections <- "collect" 


1 1 




// f is function from [1..100] into [1..10], 


19 




//it could be linear, i.e., f(cust_ value) = 


13 




// cust_volue/10 


14 




// or it could be shallower in beginning and 


15 




steeper 


16 




// towards end 


17 






18 






19 


Combining policy: 


marketing-vs-collection-cp //default is 


20 




"marketing", 


21 




any rule 


22 




with true 


23 




condition 


24 




wins 


25 






26 


Side-effect: 


no 
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FIG, 20 



1 Module: Ask_Reason_For_Call 



2 


Submodule of: routing_decisions 


3 


Input attributes: 


< none > 


4 


Output attributes: 


IVR_choice 


5 


Enabling condition: 


cust_ value < 7 and DNIS not = 


6 


"Australia_promotion" 


7 


Type: foreign 


8 


Computation: 


X := IVR_dip( question(2) ) ; 


9 




if X = 1 then IVR.choice := "dom"; 


10 




else if X = 2 the IVR_cholce := "intl"; 


11 




else IVR_choice[state] = EXC and 


12 




IVR_choice[EXC]=1 


13 






14 


Side-effect: 


yes 


15 


Side-effect-function: IVR_dip( question (2) ) 
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FIG. 21 



\ 


Module: calculate_business_value_of_call 


1 


Submodule of: 


routing_decisions 


3 


Input attributes: IVR_choice, 


4 




web.destinaUons, 


5 




frustration_score, 


6 




marketing. vs_collections, 


7 




late_payments_score» 


8 




net_profit_score 


9 


Output attributes: business_value_of_call : int 


10 


Enabling condition: true 


11 


Tun A* 

lype. 


oecision 


12 


Computation: 




13 


Kules: 




4 A 

14 




if true then business_vatue_of_call <- 


15 




{cust_value/50 * net_profit^score) 


16 




if true then business value of call <- 


17 




1 0*f ruslration score 


18 




IT UMD - Ausiraiia_ prom lion men 


1 J 




business. value_of_call <- 100 


OA 

20 




if "Australia" in web_destinations[i].regions for 


21 




some i where 


12 




web_destinaUons[i].date_last_modified > now - 


23 




30 


24 




then business„value_of_call <- 100 


25 




if IVR_choice = *'intr* then business.value.of.call <- 


ZD 




50 


27 




if marketing. vs_collections = "collect" then 


28 




business_value_of„call <- 


29 




(late.poyments.score ♦ 


30 




accounLhistory.overdue_omount)/5 


31 


Combining policy: 


business"value-of-call-cp // Add contributions of 


32 




rules with true 


33 




conditions and round up, 


34 




default is 0 


35 






36 


Side-effect: 


no 
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FIG. 22 



1 Module; Calculate_send_bonus_check 



2 


Submodule of: rouUng_decisions 


3 


Input attributes: 


cust.rec 


4 


Output ottributes: 


send.bonus_check? 


5 


Enobling condition: 


if net_profit_score > 1000 


6 




and cusLrec.lasLsent_bonus_checl< < now - 


7 




and marketing_vs_collections = "market" 


8 




OR 


9 




If net_profit_score > 500 


10 




and frustration.score > 8 


11 




and cust_recJast.sent_bonus_check < now - 


12 




and marketing_vs_ collections = ''market" 


13 






14 


Type; foreign 


15 


Side-effect; 


yes 


16 


side-effecl-function: 


17 


issue_and_send„check($50,cust_rec.name.cust_rec,address) 
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FIG. 23 

1 Module: calLpriorily 

2 Submodule of: routing_decisions 

3 Input attributes: business_value_of_call 

4 frustrotion_score 

5 Output attributes: calLpriorlty 

6 Enobling condition: true 

7 T/pe: decision 

8 Computation: 

9 Rules: if business_value_of_call < 25 then 

10 colLpriority <- 1 

11 if 25 =< business_value_of_call < 100 then 

12 calLpriority <- 2 

13 if 100 =< business_value_of_call < 500 then 

14 calLpriority <- 3 

15 if 500 =< business. value_of_call then 

16 calLpriority <- 4 

17 if frustration_score > 8 then 

18 calLpriority <- 4 

19 if 6 =< frustration_score <= 8 then 

20 calLpriority <- 3 

21 Combining policy: coli-priority-cp // high value wins with 

22 default result 2 
23 

24 Side-effect: no 
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1 Module: colculate.skill ^ ^ 

rIG* 24 

1 Submodule of: routing_decisions 

5 Input attributes: business_value_of_call 

4 marketing_vs_collections 

5 IVR_choice 

6 DNIS 

7 web_destinations 

8 Output attributes: skill 

9 Enabling condition: true 

10 Type: decision 

1 1 Computation: 

12 Rules: if marketing_vs_collections = "collections" 

13 then skill <- ["collections", infinity] 

14 if business. value of_call > 100 

15 then skill <"]"high_tier". 40] 

16 if DNIS = "austrolia.promotion" then 

17 skill <- ["australla_promo". infinity] 

18 if "Australia" in web_destinotions[i].reqions 

19 for Sonne i where web_destinations[i].date.last_nnodified > 

20 now - 30 then 

21 skill <- p'oustralia_promo". 20] 

22 if cust_rec.estimated_income_bracket = "M00K-150K" then 

23 skill <- ["australia_promo", 25] 

25 If cusLrec.estimated_inconie_ bracket = ">150K" then 

26 skill <- [*'australia_promo", 35] 

28 if IVR.choic8 = "dom" then skill <- ["norm.Uerldom",30] 

30 if IVR_cholce = ''intl" then skill <- ["norm_«er_intl".30] 

31 . L • J 

32 if "US" in web_destinationsfi],reglons for some 

33 i where web_destinations[iJ.date_last_modified > 

34 now - 30 then 

35 skill <- ["normjier.dom", 20] 
36 

37 if "US" not in web_destinations[i .regions for 

38 some i where web_destinations[i].date_lasLmodified > now - 

39 30 then 

40 skill <- ["norm_tier_intl", 20] 

41 Combining policy: skill-cp //weighted sum policy, and ties are 

42 broken by ordering "collections", 

43 "austrolia„promo", "high. tier", 

44 "low_tierJntl". "low.tier.dom", 

45 default is 1 
46 

47 Side-effect: no 
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FIG. 25 



1 


Module:. calculate_on_queue_promo 


7 
L 


Submodule of: routing_decisions 


3 


Input attributes: 


promo.hit.list 


4 


Output Qiinbutes: 


on_queue_promo 


5 


Enabling condition: 


DISABLE if business.value > 100 or 


c 
u 


frustration_score > 5 




7 


Type: decision 




8 


Computation: 


if 60 < ACD.expected_wait_time(skill) 


9 


Rules: 


10 




then on_queue_promo <- 


11 




promo_hit_list[#l] 


12 




if business_value_of„call < 30 


13 




then on.queue.promo <- promo. hit_list[j{fl] 


14 


Combining policy: 


on-queue-promo-cp // first true wins, default 


15 




is 0 


16 






17 


Side-effect: 


no 
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FIG. 27 



ffhcit 
ah value (e): bool 


VALUE 


a\-f-Mti\t..x\^-^i, 0 hei :(| ,...a\-tf^;.i^ 
al-Apply{</.ej e^>):< 


APPLY 


ffl- <ci,...,e|i>:<oi:(i o^i^> 


TUPLING 


ah^'.i (s\-%j(.i 

ffH|ei c^|:ji{ 


BAGGING 


(rl-ei:t,...,ffl-e«:t 

^^[^ CnM^] 


USTING 


ffhunitval (e):( 


UNITVAL 




PROJECTION ON TUPLES 




(rN:[«] 


PROJECTION ON LISTS 


jf-c|t:f 


ffl-e^:[fl],ol-e2:f2 
(Tr- factor(ei ,e2):[<T_a;ii ,5_a:(2> J 


FACTOR (ON USTS) 




FACTOR (ON. BAGS) 


(rl-/fi-^t,al-S:[(i] 

OrmQp\Jj[0).[l\ 


MAP (ON LISTS) 


iT[-mnn(f\(<!\-U\ 

(frma\)\j)\:i).\i\ 


MAP (ON BAGS) 


(rl-id^:f,(rl-fl:M— t.ffhS^jf} 
ffh collect (idg, 9) (S):f 


COLLECT (ON BAGS) 


(rh.idg:«.(rt-fl:<xi-*^UI-5:[<] 
ffh collect {idg,e)(S):t 


COLLECT (ON LISTS) 
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FIG. 31 



OR 




F = 3 VALUE(F) G = 4 VALUE(G) DISABLEO(F) 
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FIG. 33 
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FIG. 40A 

Initialization n 
Based on the OL specification, compute r ows 1, 2, and 3 of the disploy;]^ 4002 
For source attribute cells or row 4 do: 

For each source attribute with volue, insert value and apply 
"attribute, value.indication"; 

For each source attribute that is disabled, apply 
"attr(bute.disabled_indication"; 
For each non-decision module 



In row 5. apply "module_uninitioli2ed_indication"; 
In row 4. apply "attribute_uninitialized_indicotion"; 
For each decision module 



In row 5, apply **module„ready.indication"; 

In row 4. apply "ottribute^uninitiolized.indication**; 

For each cell in rows 6J,8,.,apply "rule_reodyJndication" Ik 4010 

Iteration 

For each event of execution engine do 
Case on events type 

non_dec_module_enabled: L^ioi? 
in row 5, apply "module_enabled_indicotion^^^| 

non_dec_module_ready: I 
in row 5, apply "module_ready_mdication";_p^ 



4004 

'4006 
'4008 



in row 5, apply "module_ready+enabled„indication" 



non_dec_madule_ready+€nabled: L ^Qjg 



non_dec_module_comput€d: 

in row 5, apply "module_computedjndication'*; 

in row 4, label corresponding attribute cell with the value computed 
and apply 

"attribute_computcd_indication"; 

non_dec_module_value: 

in row 5, label ceil for this module as "value" and apply 
"module.valuejndication"; 

in row 4, label corresponding attribute cell with value assigned and 
apply 

"attribute_value_indication" 



'4018 



^4020 
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non_dec_module_disabled: 

in row 5, label cell for this module as "disabled" and apply 

"module.disabledjndication"; [^4022 
in row 4, label corresponding attribute cell with and apply 

"attribute_disabled_indication" _ 

dec_module_enabled+ready: 

in row 5, label cell with "enabled+reody" and apply |^4024 
*'module_enabled+ready_indication'*; 

dec_module_computed: 

in row 5, label cell with "computed" ond apply 
"module.computed.indication"; [^4026 

in row 4, label cell with the computed value and apply 
"attribute„computed_indication"; 

dec_module_value: 

in row 5, label cell with "value" and apply 
"module, value.indication"; |-^4028 
in row 4, label cell with the computed value and apply 
"attribute_value_indication"; 

dec_module_disabled; 

in row 5, label cell with "disabled" and apply 
"module^disabled.indication"; |^4030 
in row 4, label cell with "J_" and apply 
"attribute_disabled_indicaUon"; 

comp_rule_condltion_true: U-4032 
to corresponding cell, apply "rule_cond_truejndication"; | 

comp_rule_contribution_ computed: 

to corresponding cell, label with computed value and apply ^4034 
"rule_contribution_computed_indication"; 

comp.rule_contributed_ value: 

to corresponding cell, label with computed volue and apply "^4036 
"rule, contributed. value_indicalion"; _ 

comp_rule_conditlon.false: 

to corresponding cell, label with "1" and apply -^4038 
"rule_condition_false_indication"; 



EndCase 
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DATA ITEM EVALUATION BASED ON THE 
COMBINATION OF MULTIPLE FACTORS 

CROSS REFERENCE TO RELATED 
APPUCATIONS 

This application is related to U.S. patent application Ser 
No. 09/251,998, cntided Eager Evaluation of Tasks in a 
Workflow System; U.S. patent application Ser. No, 09/253, 
190, entitled Data Item Evaluation Based on the Combina- 
tion of Multiple Factors; and U.S. patent application Ser. No. 
09/253,674, entitled Dynamic Display of Data Item Evalu- 
ation; all of which were filed on Feb. 19, 1999. 

FIELD OF THE INVENTION 

The present invention relates generally to computer pro- 
cessing. More particularly, the present invention relates to 
evaluating data items where the evaluation is based on the 
combination of multiple factors. 

BACKGROUND OF THE INVENTION 

In the course of processing data, computer systems often 
need to evaluate data items based on multiple factors. In the 
particular object-focused computer system described herein 
below, an object is received by the system and the process- 
ing of that object depends on the evaluation of data items 
called attributes. These so-called attributes correspond to 
variables in no n- object- focused computer systems. 

As an example of the processing of attributes in an 
object-focused system, consider a customer call center 
which receives customer telephone calls. An attribute that 
may be evaluated is call_priority, which will be assigned a 
value depending on various factors, such as previous calls 
from the customer, input aheady received from the customer 
identifying the reason for the call, the potential value of the 
call, etc. The faaors are evaluated and the results of the 
evaluations are combined in some manner in order to 
determine the . value to be assigned to the call_priority 
attribute. The manner in which the factors are evaluated, and 
the marmer in which the results are combined, are defined by 
some business policy regarding the handling of calls. Once 
the business policy is articulated, it must be specified in a 
manner understandable to a computer system implementing 
the call center. 

One technique for specifying the business policy is to 
encode the decision making process into a conventional 
procedural computer program which defines the steps to be 
taken in evaluating the attribute, and the order of those steps. 
Such a procedural specification defines how each factor is to 
be evaluated, and how the results of the factor evaluations 
are to be combined in order to assign a value to the attribute. 
Due to the nature of procedural programming languages, the 
resulting specification for implementing the business policy 
will generally be awkward, and dif&cult to maintain and 
modify. For example, it will be difficult to separate the 
portions of the specification defining how the factors are to 
be evaluated from the portion of the specification defining 
the algorithm for combining the results of the factor evalu- 
ations. 

One technique which solves some of the problems of the 
above described procedural specification is the use of an 
expert system. Expert systems are rules-based systems 
which allow for the specification of a body of rules and an 
algorithm for applying those rules to some input. However, 
the use of an expert system generally only allows for a single 
algorithm describing how rules are to be appUed and 
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interpreted, and as such there is a degree of inflexibility in 
such a system. Also, the specification of the computation 
rules for a variety of attributes may require the definition of 
many rules, with the interaction of those mles being intricate 

5 and difficult to understand. Further, expert systems are 
generally slow and inefficient, and are generally unsuited for 
applications which do not require the full processing power 
of an expert system. 
As such, there is a need for an improved technique for the 

10 specification of how attributes are to be processed based on 
a combination of multiple factors. 

SUMMARY OF THE INVENTION 

j5 In accordance with the invention, data items are evaluated 
in accordance with associated computation rules and a 
combining policy. The computation rules specify the factors 
to be taken into account in the evaluation of the data item, 
and how the factors are to be evaluated. The combining 

20 policy specifies how the results of the evaluation of the 
factors are to be combined in order to assign a value to the 
data item. 

The computation rules comprise a condition and a term. 
The evaluation of a computation rule consists of the evalu- 
25 ation of the condition, and if the condition is true, then 
contributing the term to a collection of values. The collec- 
tion of values is then combined in accordance with the 
combining policy to produce a value which is assigned to the 
data item. 

30 In accordance with one aspect of the invention, the 
combining policy is specified by a flexible combining policy 
language. Tlie combining policy may also be specified using 
a combining policy function, which represents a predefined 
combining poUcy language program. 

The use of computation rules and a combining policy in 
accordance with the invention provides for a powerful and 
flexible technique for evaluating data items based on the 
combination of factors. Further, a program specification in 
accordance with the invention is easy to maintain and 

^ modify because the specification of how factors are to be 
evaluated are specified by the computation rules, and the 
specification of how the factor evaluation results are to be 
combined are specified by the combining policy. This sepa- 
ration resiilts in a specification which is easier to understand, 
maintain, and modify. 

These and other advantages of the invention will be 
apparent to those of ordinary skiU in the art by reference to 
the following detailed description and the accompanying 
drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 shows a high level block diagram of an object 
focused workflow system; 
55 FIG. 2 shows a graphical representation of an example 
declarative language specification; 

FIG. 3 shows a graphical representation of a flowchart 
module portion of the example declarative language speci- 
fication; 

60 

FIG. 4 shows the textual representation of the flowchart 
module shown graphicaUy in FIG, 3; 

FIG. 5 shows a graphical representation of a declarative 
module portion of the example declarative language speci- 
g5 fication; 

FIG. 6 shows the textual representation of the declarative 
module shown graphically in FIG. 5; 
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FIG. 7 shows the textual representation of a foreign FIG. 30 shows the finite state automata for a side -effect 
module portion of the example declarative language sped- attribute; 

fication; FIG. 31 shows the condition tree for an example enabling 

FIG. 8 shows the textual representation of a foreign condition; 
module portion of the example declarative language speci- ^ FIG. 32 shows a data and enabling flow diagram; 
fication; FIG. 33 shows a dependency graph; 

FIG. 9 shows a graphical representation of a declarative FIGS. 34A-34D show pseudo code for the basic algo- 
module portion of the example declarative language speci- rithm for determining whether a task is eligible or unneeded; 
fication; FIGS. 35A-35G show pseudo code for the extended 

FIG. 10 shows the textual representation of the declara- algorithm for computing whether an attribute is necessary; 
tive module shown graphically in FIG. 9; FIG. 36 shows the finite state automata for decision 

FIG. 11 shows the textual representation of a decision modules; 
module portion of the example declarative language speci- FIG. 37 shows the finite state automata for computation 
fication; 15 rules; 

FIG. 12 shows the textual representation of a foreign FIG. 38 shows an illustrative display screen shot of the 
module portion of the example declarative language speci- graphical user interface; 

fication; FIG. 39 shows an illustrative display screen shot of the 

FIG, 13 shows the textual representation of a foreign graphical user interface; and 
module portion of the example declarative language speci- 20 FIGS. 40A and 40B show pscudo code for the algorithm 
fication; for maintaining and dynamically updating the graphical user 

FIG. 14 shows the textual representation of a forcigp interface display, 
module portion of the example declarative language sped- DETAILED DESCRIPTION 

fication; ^ ^ jj jgjj i^y^i block diagram of an object-focused workflow 

FIG. 15 shows the textual representation of a decision system in which the present invention may be implemented 
module portion of the example declarative language speci- is shown in FIG. 1. As used herein, a workflow system is a 
fication; system that facilitates the systematic execution of activities 

FIG. 16 shows the textual representation of a dedsion and tasks on a class of similar input objects based on 
module portion of the example declarative language sped- 3q common modules and/or functions. The workflow system 
fication; may treat most or all of the objects in a uniform way, or may 

FIG. 17 shows the textual representation of a decision H£at the input object m highly diilerentiated ways. A n 
module portion of the example declarative language speci- instance ot the workflow includes the processing that is 
fication; perfonmed by the workflow system and by external compo- 

nO.'lS shows the textual representation of a decision 35 nents as a result of an input object being provided to the 
module portion of the example declarative language speci- workflow system. Multiple mstances of the workflow might 
fication; execute sunultaneously. Tpe workflow system may operate 

, , , . , , . . in realtime, near real-time, or at slower speeds. In accor- 

FIG 19 shows the textual representation of a decision d l^ ^th the embodiment shown m FIG. 1, jE T^^ X- 
module portion of the example dedarative language speci- ^ foc^L^^Z^ 100 irnplements a ciistomer 'dare 

hcation, s ystem for'processing'incoming calls. ^ Ut course the tecla- 

FIG. 20 shows the textual representation of a foreign niques described iicrem may be used 'to implement many 
module portion of the example dedarative language sped- different types of systems, such as electronic commerce 
fication; systems. The system 100 includes a Declarative Language 

FIG. 21 shows the textual representation of a decision 45 (DL) specification 102, a decision engine 104, a graphical 
module portion of the example declarative language speci- user interface (GUI) 105, and an abstraction layer 106. 
fication; DL specification 102 represents a specification describing 

FIG. 22 shows the textual representation of a foreign the desired operation of the object- focused workflow system 
module portion of the example declarative language speci- 100 upon the receipt of some object. For example, the object 
fication; 50 may be the receipt of an incoming telephone call to the 

FIG. 23 shows the textual representation of a decision customer care system. At least a portion of the DL specifi- 
module portion of the example declarative language speci- cation 102 includes a declarative description of the operation 
fication; of the system. The declarative description explicitly 

FIG. '24 shows the textual representation of a dedsion describes the steps to be taken during workflow execution, 

module portion of the example dedarative language sped- 55 but the order of those steps is imphat m the DL specification 

fication; ^ ^ departure from the prior art workflow systems 

r-ii^ -»c i_ .L * * 1 . r J • • which gcneraUy describe workflow procedurally, that is, the 

FIG. 25 shows the textual representation of a decision c i- -.i . . .1. : * u ; 1 j • 

J 1 ^ . c 1 / 1 . • 1 * specification explicitly states the steps to be taken during 

module portion of the example declarative language speci- a r.i . ^ 

ti o o r workflow execution and the sequence of those steps. The 

. , * , .. n 1. 60 benefit of a declarative workflow spedfication is that it 

HG, 26 shows a data and enablmg flow diagram; ^y^^g ^ ^^^^^ ^^^^^ ^^^^ ^^^^ ^^^^ ^ 

FIG. 27 shows the typing niles for Combining Policy application and lets the underlying computer system address 
Language operators; implementation details, including the particular order in 

FIG. 28 shows a high level functional diagram of a which steps should be taken. The details of the DL speci- 
decision engine; 65 fication 102 will be described in further detail below. 

FIG. 29 shows the finite state automata for a non-side- The decision engine 104 receives the DL specification 102 

effect attribute; and processes objects in accordance with the DL spcdfica- 
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tioD 102. Such processing of objects inchides the control of 
various external components 108 such as a private branch 
exchange (PBX) 110, interactive voice response unit (IVR) 
112, outbound call processor 114, e-commerce server 116, 
and database 120. These components are external in that 
they are not part of the workflow system 100, but may be 
controlled by the workflow system 100 during processing of 
an object. Only one of each of these external components is 
shown in FIG. 1 for clarity, however external components 
108 may include more than one of each of these compo- 
nents. For example, it would be common for the external 
components to include multiple databases. Further, the 
external components 108 shown in FIG. 1 is only an 
illustrative list of the types of components that may be 
controlled by an object-focused system implementing a 
customer care system. An object-focused system implement- 
ing other types of systems would likely contain other types 
of components. 

A graphical user interface 105 is provided for displaying 
a representation of the execution of the workflow on a 
computer display screen and will be described in further 
detail below. 

An abstraction layer 1 06 is provided between the decision 
engme'j^l R and the external components 10 8 so th^ \ f\e, 
decision epgine 104 may communicate with and control th e 
external components using a high level communication 
protocol, without the need to deal with the particular com - 
munication' pro tocol s of each of the different external j om- 

|^nnpr^[<^ ig paTtirn larly ngpfiil hpfangf the external 

components 108 will generally be heterogeneous with dif- 
ferent components being manufactured by different compa- 
nies. T^^^ ahstr actinn la yer 106 i^ cln^efi qp integrgtpd view 
1 22, system wrappers 124^ and d^^ ^ ^ ^VS^^ ivrayij TKrjJ26 
Tpe system wrappers l24 provide abstract interfaces to the 
external components ,108» exposing properties relevant t o 
t he workflow application while hiding irrelevant deta ils 
concerning particularities of the components' interlaces an d 
a spects of the components" bebavior/rbc data so urcewgp- 
pers 126 provide abstract interface s' to the "dafatiascsa^d 
reporting features ot tne otner exiemal components 108 , 
e3cposing relevant data and update capabilities._ 'llie inte- 
grated view 122 provides a unified interface to the function- 
alities supported by the external components 108, using 
abstract data types or similar interfacing modules. For 
example, the integrated view 122 may expose a functionality 
without exposing what components the fiinctiopality is 
implemented by, and expose a computed data set without 
showing what databases the raw data is residing on. 

TTie decision engine 104, GUI 105, and abstraction layer 
106 are high level representations of functions that may be 
performed by one or more appropriately programmed com- 
puters. The components of such computers are well known 
in the art and the details of such computers will not be 
described herein. 

The contents of the DL specification 102 will now be 
described. In the embodiment described herein, the DL 
specification 102 comprises a textual specification which is 
provided to the decision engine 104 for processing. 
However, the DL specification 102 may be represented in 
other ways as well. For example, the DL speci^cation 102 
may comprise a graphical specification which is provided to 
the dectsioo engine via data structures. The description of 
the DL specification 102 will be provided in conjunction 
with an example application of a travel agency customer 
care system. It is noted that the sole purpose of describing 
the DL specification 102 in conjunction with a particular 
example is to provide a context for describing the principles 
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of the present invention. The use of the travel agency 
example used herein provides such a context. The purpose of 
this description is not to provide a complete description of 
how to implement a travel agency call center. Therefore, the 

5 example graphical and textual descriptions included herein 
will only be described in enough detail so as to clearly 
describe aspects of the present invention. Further, although 
a fair level of detail is provided with respect to the example, 
not all details of the figures (in particular the textual 
specification) will be described herein. Further, the example 
is not to be taken as a complete description of the specifi- 
cation needed to implement such a travel agency call center. 
Portions of the specification which would be required to 
implement the example have been omitted for clarity. 
Fuxther, portions of the specification have been included 
solely for the puirpose of describing a certain aspect of the 
invention, and such portions may be inconsistent with other 
portions of the specification which have been included to 
describe certain other aspects of the invention. 

2Q In accordance with the example, it is assumed that a travel 
agency call center receives incoming calls from customers. 
The object passing through the system in this example is an 
incoming call, and the system operates to determine how to 
route the incoming call and what so-called side-effects 

25 should be executed. Side-effects will be described in further 
detail below. Assume that the call center has multiple agents, 
and each agent has one of 4 skill levels numbered 1-4. Each 
of the skill levels represents a particular level of expertise in 
a different type of cafl. During operation, it is desirable to 
route calls to appropriate agents in order to best utilize the 
agents' skiUs. Further details regarding the example appli- 
cation will be described below. 

FIG. 2 shows a graphical representation of a DL specifi- 
cation for one portion of the travel agency example. More 

35 particularly, FIG. 2 shows a graphical representation of the 
Routing_To_Skill module 202 which will determine, based 
on various parameters of an incoming call, how to route the 
call. The term module is used herein to describe a logical 
grouping of related processing functions. The input param- 

40 eters to the Routing_To_Skill module 202 arc ANI, DNIS, 
WEB_DB_LOAD, and PR0MOS_0F_THE_DAY. The 
output parameters of the Routing_To_Skill module 202 are 
SKILL, ON_QUEUE_PROMO, and WRAP__UP. These 
input parameters and output parameters are called attributes. 

45 The term attribute is used herein to describe a data item 
associated with an object which may be evaluated during 
processing of the object. An attribute in an object-focused 
workflow system is similar to a variable in a procedural 
system. 

50 For purposes of this discussion, since the Routing__To__ 
Skill module 202 is the highest level module described, it is 

assumed that values for the input attributes to the Routing 

To_Skill module are provided to the system prior to execu- 
tion of the workflow. Such attributes which are provided 

55 from some external source are caUed source attributes. 
Similarly, the output attributes of the Routing_To_Skill 
module are called target attributes, because these arc the 
attributes for which values are produced when processing is 
completed. Attributes which are used during processing 

60 which are neither source attributes nor target attributes are 
called internal attributes. 

There are four types of modules in a DL specification. 
Declarative modules have a declarative semantics and con- 
tain sub -modules. Declarative modules are represented in 

65 the figures using rounded corner rectangles. Decision mod- 
ules produce a single attribute value through a novel tech- 
nique for aggregating and synthesizing information using 
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computation rules and a combining policy in accordance 
with an aspect of the invention which will be described in 
further detail below. Decision modules are represented in the 
figures using solid line hexagons. Flowchart modules are 
specified using a flowchart language to describe the pro- 
cessing. Flowchart modules are represented in the figures 
using rectangles with a cut comer. Foreign modules are 
implemented using some type of external function (e.g. 
database query or web server routine). Foreign modules are 
represented in the figures with a rectangle. Eadi of these 
types of modules will be described in further detail below. 

As shown in FIG. 2, the Routing_To_Skill module 202 
is made up of six sub-modules: ldentify_Caller 210, Info_ 
About_Customer 220, Info Jrom_Web 230, Promo_ 
Selection 240, Routing_Decisions 250, and Calculate_ 
Wrap_Up 260. Module 210 is represented as a rectangle 
with a cut corner indicating that it is a flowchart module. 
Modules 230 and 240 are represented as rectangles which 
indicates that these modules are foreign modules and obtain 
values for attributes by executing external functions. Mod- 
ules 220 and 250 are represented as rounded comer 
rectangles, which indicates that these modules are declara- 
tive modules which are specified at a lower level using 
another DL specification. These types of modules are used 
to conveniently represent at a high level a substantial 
amount of lower level processing. Such high level repre- 
sentation makes it easier for a designer to visualize the 
overall function of a DL specification. Module 260 is 
represented as a hexagon, which indicates that this module 
is a decision module and evaluates a single attribute using 
computation rules and a combining policy in accordance 
with an aspect of the invention which will be described in 
further detail below. 

Each module has input attributes and output attributes. As 
will become clear from the description which follows, the 
workflow system 100 is attribute-based, that is, much of the 
processing which occurs in the workflow system is based on 
the evaluation of attribute values. Attributes are assigned 
triples as follows: (State, Value, Exception- Value) where: 



State 


€ {VALUE, EXCEPTION, DISABLED. 




UNINITIALIZED, FAIL) 


Value 


° a value if State - VALUE 




± otherwise 


Exception- Value 


= exception value if State » EXCEPTION 


J. otherwise 
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The meaning of these states is as follows. VALUE indicates 
that the attribute currently has a value assigned to it. 
EXCEPTION indicates that there has been some error in 
evaluating the attribute. DISABLED indicates that it has 
been determined that the attribute will not be assigned any 
value. It is noted that a DISABLED State does not indicate 
any error, but is part of normal processing. UMNITIAL- 
IZED indicates that essentially no information is available 
about the attribute. FAIL indicates that the module defining 
the attribute was enabled (as described below), but aborted 
before producing a state of VALUE, EXCEPTION, or 
DISABLED for the attribute. It is also noted that attribute 
assignments arc monotonic, that is, once an attribute is 
assigned a state other than UNINITIALIZED, further pro- 
cessing of the workflow object will not change the state and 
any assigned value. 

The value of an attribute wiU be some value assigned to 
the attribute if the state of the attribute is VALUE. 
Otherwise, the value will contain X, which indicates no 
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value. The Exception-Value of an attribute will contain an 
exception value indicating a particular error condition if the 
state of the attribute is EXCEPTION. Othenvise, the 
Exception- Value will contain 1. 

Modules also have associated states. Module states are 
UNINITIAUZED, SUCCESS, EXCEPTION, and DIS- 
ABLED. The module state UNINITIALIZED indicates that 
essentially no information is available about the module. 
The module state SUCCESS indicates that the enabling 
condition (as described below) for the module was true, and 
the module executed successfully. The module state 
EXCEPTION indicates that the module was enabled, but an 
exception occurred. The module state DISABLED indicates 
that the module's enabling condition is false. 

Each of the modules is associated with an enabling 
condition, which is a condition which determines whether 
the module will be evaluated for a given input object. 
Enabling conditions can refer to attribute values, attribute 
exception values, attribute states (e.g., whether the attribute 
has a value or whether an exception occurred when attempt- 
ing to evaluate it), module states and module exception 
values. The enabling conditions are graphically represented 
as broken line hexagons 211, 221, 231, 241, 251, 261. 
Enabling conditions 211, 251, and 261 contain TRUE, which 
will always evaluate to a true condition, and therefore the 
Identify_Caller module 210, Routing_Decisions module 
250, and Calculate__Wrap_Up module 260 will be evalu- 
ated for each input object. Enabling condition 221 contains 
the expression: VAL (ACCOUNT_JWMBER). The func- 
tion VAL (X) will return a true condition if the attribute X 
is in the state VALUE, otherwise, false will be returned. 
Therefore, the enabling condition 221 indicates that the 
Info_About_Customer module 220 will be evaluated if the 
attribute ACCOUNT-NUMBER is in the state VALUE. If 
the attribute ACCOUNT-NUMBER is in state 
EXCEPTION, DISABLED, or FAILED, then enabling con- 
dition 221 will evaluate to false and the Info _Aboul_ 
Customer module 220 will not be evaluated. If the attribute 
ACCOUNT_NUMBER is in state UNINITIAUZED, then 
enabling condition 221 cannot yet be evaluated. Thus, the 
evaluation of enabling condition 221 depends on the 
attribute ACCOUNT-NUMBER first receiving a state other 
than UNINITIALIZED. It is noted that this dependency is 
implicit in the DL specification and not explicitly specified 
by the system designer or programmer. 

Various expressions can be used for enabling conditions. 
For example, enabling condition 231 indicates that the 
Info-Frora_Web module 230 will be evaluated if the value 
of the WEB_DB_LOAD attribute is less than 95% or if the 
ACCOUNT_NUMBER attribute does not have a value. 
Enabling condition 241 indicates that the Promo_Selection 
module 240 will be evaluated if the CUST_JlEC.IIArES- 
PROMOS attribute is false. 

FIG. 2 gives a high level graphical representation of the 
DL specification of the Routing-To-Skill module 202. Rel- 
evant portions of each of the sub-modules will now be 
described. A graphical representation showing further detail 
of the Identify_Caller module 210 is shown in FIG. 3. The 
DL specification in textual language corresponding to the 
graphical representation of FIG. 3 is shown in FIG. 4. 

As shown in FIG. 4, the module name is specified in line 
1, and an indication of which module the current module is 
a sub-module of is given in line 2. The next section defines 
the input attributes (line 3). The next section defines the 
output attributes (hnes 4-14). Line 15 specifies the enabling 
condition, which corresponds to the enabling condition 211 
shown in FIG. 2. The type of the module, in this case 
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flowchart, is specified on line 16. TTie computation section caller by asking him/her to input some information. Upon 

of the textual specification (line 17) indicates how attributes receipt of the home phone number, the ACCOUNT_ 

arc to be evaluated. For this module, the attributes will be NUMBER and CUST JEC attributes are retrieved in step 

evaluated according to the flowchart shown in FIG. 3. Of 312 in a manner similar to that in step 304. If one customer 

course, one skilled in the art could convert the flowchart of 5 is identified then the test in step 314 will be true and in step 

FIG. 3 to program code to implement the logic flow shown 316, the ACCOUNT_NUMBER, CUST_REC, and 

in FIG. 3. Such code is not inchided in FIG. 4 because it is HOME_PHONE attributes arc assigned values. If one cus- 

not necessary for an understanding of the principles of the tomer is not identified, then the test in step 314 will be false 

present invention. Finally, line 18 indicates that this module and in step 318 the HOME-PHONE attribute is assigned, 

has a side-effect. The side-effect action is an interactive lo and the ACCOUNT_NUMBER and CUST-REC attributes 

voice response (TVR) unit dip (line 19). arc disabled. 

A side-effect action is an action which has a significant The DL specification further defining the Info_^bout_ 

impact on a system or user that is external to the workflow Customer module 220 (FIG. 2) is shown graphically in FIG. 

system. Stated another way, the execution of a side-effect 5 and tcxtually in FIG. 6. This Info_About_Customer 

action imparts a substantial overhead on the workflow 15 module 220 is a declarative module and is therefore further 

system. Some actions may be deemed as being side -effect defined in terms of sub- modules. The Get_Rccent_ 

actions because a cost is associated with each occurrence of Contacts J'or_This__Cus tomer modtile 504, the Get_ 

the action. For example, queries against some databases may Recent__Purchases__For„This_Customer module 508, the 

have no associated cost because the databases are main- G6t_j\.coount_History_por_This_Customer module 512, 

taincd by the same organization that maintains the workflow 20 and the Calculate_Cust_Value module 528 will always be 

system, while queries against other databases may have evaluated because their respective enabling conditions 502, 

associated costs because the database is maintained by an 506, 510, 526 are always true. It is noted that the graphical 

external organization. An action may be considered to be a representation of these modules indicate that they are for- 

side-effect action if the effect of the action cannot be undone eign modules. Each of these modules performs an external 

by a subsequent separate action. Side-effects may include 25 database retrieval function. If the attribute RECENT_ 

actions such as executing financial transfers, issuing checks CONTACTS has a state of VALUE, then the enabling 

or other instruments of monetary value, invoking actions by condition 514 will be True and the Calculate_Frustration_ 

other workflow engines, updating databases that are used by Score module 516 will be evaluated. If the attribute 

other software systems or users, or engaging users in an RECENT_CONTACTS has state EXCEPTION, 

activity. An internal action is an action that is not a side- 30 DISABLED, or FAILED, then the enabUng condition 514 

effect action. As described above in connection with line 18 will be False and the Calculate__Frustration_Score module 

of FIG. 4, an indication of whether a module includes a side 516 will not be evaluated. If the attribute RECENT_ 

effect action is included in the DL specification. CONTACTS is in state UNINITIALIZED, then enabling 

The details of how attributes are evaluated by the condition 514 cannot yet be evaluated. Enabling conditions 

Identify_CaIler module 210 are given in the flowchart of 35 518, 522 and 530 are evaluated in a similar manner. The 

FIG. 3. The decision of step 302 determines whether the modules 516, 520, 524, 528, and 532 are all represented as 

attribute ANT has a value. As shown in FIG. 2, ANI is a solid line hexagons, which indicates that these modules are 

source attribute which is an input to the high level Routing_ decision modules and the processing of these modules is 

To_Skill module 202, and represents the telephone number specified in terms of computation rules and a combining 

from which the incoming call originated. Since such a 40 policy, as will be described in further detail below, 

telephone number is not always available, the decision in The corresponding textual DL specification of the Info_ 

step 302 is needed. If the ANI attribute has a value, then in About_Customer module 220 is shown in FIG. 6. It is noted 

step 304 the ACCOUNT-NUMBER and CUST„REC that the type of the module as specified in line 16 is 

attributes for the customer associated with the ANI are declarative, indicating that the module is a high level 

evaluated by performing a lookup to an external database. If 45 abstraction of processing details which are specified using 

the decision in step 306 indicates that one customer has been sub-modules with enabling conditions, 

identified, then in step 308 the attributes ACCOUNT__ Returning now to FIG. 2, the Info_From_Web module 

NUMBER and CUST-REC are assigned the values retrieved 230 will now be described in further detail. Module 230 is 

in step 304. The assigning of values to the attributes represented as a rectangle, which indicates that this is a 

ACCOUNT_NUMBER and CUST-REC includes assigning 50 foreign module which obtains values for attributes by 

values to the associated tuple: (State, Value, Exception- executing external fiinctioos. The enabling condition 231 of 

Value) for each of the attributes. Thus, the state of these module 230 indicates that the modiile will only be evaluated 

attributes becomes VALUE, the value gets the value if the attribute WEB_DB_LOAD has a value which is less 

retrieved, and exception-value is assigned L, as described than 95% or if the attribute ACCOUNT_NUMBER has a 

above. Further, in step 308, the attribute HOME _J>HONE is 5S state other than VALUE or UNINTITAUZED. The textual 

disabled, such that its associated tuple (State, Value, DL description of the Info_From_Web module 230 is 

Exception-Value) is updated such that state becomes shown in FIG. 7. The computation specified in line 13 

DISABLED, value becomes 1, and exception-value indicates that data from an external web server will be 

becomes 1. As described above, since attribute assignments obtained using the attributes ANI, HOME_J'HONE, and 

are monotonic, the values and states for these attributes will 60 ACCOUNT_NUMBER. The information returned will be 

not change during further processing of this particular assigned to the attribute WEB_DESTINAnONS, which 

incoming telephone call. will contain information regarding a customer's prior inter- 

If the test in step 306 is false, then in step 310 the actions with an associated Internet web site, 

customer is asked for a home phone number Such a step The Promo__Selection module 240 will now be described 

may be performed by initiating such a request from an 65 in further detail. Like module 230, module 240 is repre- 

interactivc voice response unit, such as unit 112 (FIG. 1). sen ted as a rectangle, which indicates that this is a foreign 

Step 310 specifies a side-effect action because it impacts the module which obtains values for attributes by executing 
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external functions. The enabling condition 241 of module 
240 indicates that the module will only be evaluated if the 
attribute CUSTJlEC.HATES_PROMOS has a value 
False. The textual DL description of the Promo_Selection 
module 240 is shown in FIG. 8. The computation specified 5 
in lines 15-18 indicates that data from an external source 
(e.g. a database, expert system, another workflow system) 
vkiU be obtained using the input attributes. The information 
returned will be assigned to the attribute PROMO^HFI- 
UST, which will contain a list of promotions which would 
be appropriate to present to a customer during a call. 

The DL specification further defining the Routing_ 
Decisions module 250 (FIG. 2) is shown graphically in FIG. 
9 and textually in FIG. 10. This Routing_Decisions module 
250 is a declarative module and is therefore further defined 
in terms of sub-modules. The Ask_Reason_„For_Call mod- 15 
ule 910 will be evaluated if the CUST_VALUE attribute has 
a value less than 7, as indicated by enabling condition 912, 
Module 910 is represented as a rectangle, which indicates 
that the module is a foreign module. This module 910 
performs an IVR interaction asking the caller the reason for ^ 
calling, and the reason is assigned to attribute IVR_ 
CHOICE. Modules 920, 940, and 950 wiU all be evaluated 
because their associated enabling conditions 922, 942, and 
952, are all True. Module 960 will not be evaluated if the 
attribute BUSINESS_VALUE is greater than 100 or if the 
attribute FRUSTRAnON_SCORE is greater than 5. This ^ 
enabling condition 962 illustrates that enabling conditions 
can also specify when a particular module is disabled, rather 
than specifying when it is enabled. Module 930 will be 
evaluated if the test in its enabling condition 932 is True. The 
modules 920, 940, 950, and 960 arc represented as 30 
hexagons, which indicates that these modules are decision 
modules and that their attributes are evaluated using com- 
putation rules and a combining policy. These modules will 
be described in further detail below. Module 930 is repre- 
sented as a rectangle which indicates that this is a foreign 35 
module. 

The corresponding textual DL specification of the 
Routing__DecisioDS module 250 is shown in FIG. 10. The 
type of the module (line 20) is declarative, and is therefore 
further defined in terms of sub -modules. ITius, the module is ^ 
a high level abstraction of processing details which are 
specified using sub-modules with enabling conditions. It is 
noted that line 21 of the textual DL specification indicates 
that the module has a side-effect. This side effect is a result 
of the Calculate_Send_Bonus_Check module 930 and will 
be described below in conjunction with that module. 

Referring back to FIG. 2, the final module in the 
Routing_To_Skill module 202 is the CalcuIate_Wrap_Up 
module 260. Calculate_Wrap_Up module 260 is graphi- 
cally represented in FIG. 2 as a hexagon, which indicates 
that the module is a decision module and that the processing so 
of the module is specified in terms of computation rules and 
a combining policy. The use of computation rules and a 
combining policy to evaluate attributes in accordance with 
the invention will now be described in detail. 

In general, the format of computation rules and a com- 55 
bining policy within a DL specification is as follows: 

Computation rules: 
If condition-1 then Attribute-^term-1 
If condition-2 then Attribute<-term-2 . . . 
If condition-n then Attribute^term-n go 

Combining Policy: 
Program in Combining Policy Language (CPL) or CPL 
function. 

In the above format, the specification of: 

If condition then Attribute-^term 65 
indicates that the term contributes to Attribute if the condi- 
tion has a True value. Thus, each of the computation rules is 
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evaluated to determine whether the condition is True or 
False, If the condition is True, then the term contributes to 
the attribute. If the condition is False, then the term does not 
contribute to the attribute. After each of the computation 
rules has been evaluated, the attribute is assigned a value 
based on the combining policy language (CPL) program, or 
the CPL function (where the CPL function is specified by a 
CPL program). Thus, the computation rules only contribute 
their terms to attributes, which is different from assigning a 
value to the attribute. The attribute is only assigned a value 
based on the combining policy (e,g. CPL program or CPL 
function). For example, a CPL function may indicate that the 
highest value of the contributed terms is to be assigned to the 
attribute or that the sum of all the contributed terms is to be 
assigned to the attribute. 

It is noted that the use of computation rules and a 
combining poUcy has been described in the context of the 
object-focused workflow system in accordance with one 
embodiment of die invention. As such, computation rules 
and combining policies arc used to assign values to 
attributes. It is to be understood, however, that the use of 
computation rules and combining policies in accordance 
with the principles of the present invention is not limited to 
use in an object-focused system. More generally, computa- 
tion rules and combining policies may be used to evaluate 
any type of data item, whether that data item is an attribute 
in an object-focused system, a variable in a procedural 
system, or some other type of data item. 

CPL provides a flexible and powerful mechanism that 
allows designers to specify how computation rules are to be 
combined in order to assign a final value to an attribute. CPL 
will first be specified formally using mathematical notation 
such that one skilled in the art of computer science could 
implement the language. Following the formal description, 
examples of how the language would be used to build useful 
combining functions will be described in conjunction with 
the ongoing example. 

First, the values and types of the CPL langiiage will be 
described. Then, the operators that form an algebra for the 
language will be defined. 

CPL applies on homogeneous collections of data and is 
based on a type system that defines the following value 
types. Each CPL type admits 1 (standing for "undefined") as 
a specific occurrence. The type definitions are as follows. 

atom (e.g. bool, int, float, string) 

<al: Tj, . . . , an: T„>is a tuple type, if each T, is a value 
type. 

[T] is a homogeneous list type, if T is a value type. 

{T} is a homogeneous bag type, if T is a value type. 

AM: TjX ... X T„-*Tis an atomic mapping type if Tj, . . . , 
T„ and T are atom types. This type allows the definition 
of arbitrary mappings over atoms. 

Values in CPL are defined as follows: 

1 is a CPL value called undefined. 1 can be of any type. 
In others terms, 1 belongs to all the domains of all the 
CPL types. 

Any atom's value is a CPL value. 

Any finite tuple (ai:Vi, . , . , a„:v,^ of CPL values is a CPL 
value if aj, . . . , a„ are names for the fields in the tuple 
and Vj, . . . , v„ are CPL values. 

Any bag and any list of CPL values of a given type is a 
CPL value, {a,, . . . a„} is used to represent the bag 
value that contains the values a^, . . . a„. [aj, , . , a„] is 
used as a shorthand to represent the list value that 
contains the values a^, . . . a„ and whose first element 
is a^, second element is a^ and n''' element is a„. 
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Any arbitrary function defined over atoms is a CPL value. 
A function / of type AM: Tj x . . . x T„-*T has for input 
types the atom types . , . T„ and for retm-n type the 
atom type T. 

In CPL, variables are assigned types using type inference, as 
commonly found in functional programming languages such 
as ML. The inference rules used in CPL arc detailed below. 
A CPL program is a sequence of declarations of variables 

and/or functions: 
idi :: = ■■ 

id2 :: = ■• 



where id^, idj, ... are variable or function identifiers. A 
variable declaration has the form: 
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/•(value (e))»if /*(«)«^ then False else, True 

The AMapply operator performs as follows: 

/*(AMapp)y if,e,,..., O)-W(/*(«0> ■-■> ^'(0) 

Where / is any atomic mapping that applies on n atom 
values and returns an atom value. 

Constructor operators are now described. A constructor 
operator is an operator which builds a composite object (e.g. 
tuple, list, bag) from other objects. 

Hic operator tupling is defined as follows: 

/*(ttipliiig(al;»Ci, . . . ,an .•-ej)"<fll: /*(Ci), .... an :!*(%)> 
/*(tiTliiig(J.))-l 
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where e is an expression of CPL. A variable declaration is 
well formed if the firce variables used in e are previously 
defined in another variable declaration statement (no recur- 20 
sive variable declaration is allowed). A function declaration 
has the form: 

where e is an expression of CPL. A function declaration is 
well formed if 

Vi e 1 ... n, X,- is a variable, and 

the free variables used in e either are previously defined in 
a variable declaration statement or belong to {Xj, 
X2, - • . ,x„}. (Recursively defined functions are not 
allowed). 

The syntax of expressions depends on their types. Built-in 
operations ^) that are associated with the built-in atom 
types are allowed. Also allowed are some Boolean expres- 
sions such as e^ and c^, Cj or e2, ""ej and a conditional if e 
then Ci else e^ where e is a Boolean expression and e^jG^ 
have the same type. Expressions can also be constructed 
using the operators defined below. FIG. 27 presents the 
typing rules for these operators. Names starting with v in 
FIG. 27 represent variable names, names starting with e 
represent terms in the CPL calculus, and names starting with 
t represent types. The notation a«e:t indicates that the term 
e is assigned the type t under the substitution 0. If a type 
equation is a fraction, the numerator is the premise while the 
denominator is the consequence. 

The interpretation of the operators of CPL is now 
described. I*(e) represents the interpretation of an expres- 
sion e. If e is a variable name or a function name, I*(e)=I(e) 
where the interpretation I associates variables to values and 
function names to functions of the appropriate type. (If e is 
a constant, 1(e) =(e)). 

The value operator performs as follows: 



The operator bagging is defined as follows: 
/'(IjaggingCe,, .... 0)-U'(«i). • • • >/'(0} 
/•(baggmg(l))-l 

The operator listing is defined as follows: 
/•Oistmg(c», .... cJHf-CO. - ■ . /'(Ol 
/•(ltstmg(J.))-J. 

As a shorthand, we use <aj:=ei, . . . , a„:=e„>, {e^ . . . , 
and [e^ . . . , e„] to respectively note tupling (a^roCj, . . . , 
a„:=ej, bagging(e„ . . . , ej, and listing(ej, . . . , ej. 

Dcconstructor operators arc now described. A dcconstruc- 
tor operator is an operator which extracts a component 
object from a composite object. 

The unitval operator is defined as follows: 



l*(ujutval(S)) » UNrrVAL(I*(S)) 

UNnVAL({})) - UNrrvAL{±)) - X 

UNnVAL({ai, . . . , a„}) 



• if a B 1 
■ 1 if n ^ 2 



The operator Proj^, is a parameterized operator. A param- 
eterized operator is an operator which is defined using a 
template with parameters. Specific operators are formed 
from a parameterized operator by specifying a value for 
these parameters. The Proj,,; operator is defined as follows: 



r (proj„.(<a/«^ . . . 



where ie{l , . . n}. 
35 The getelt, operator returns the i'* element of a list. It is 
defined over lists as follows: 
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P{getelti(L)) 
GEreUTidai, . 
GETIELTiaai, . 
GEI1ELT,(1) 



GETEUi(I*(L))) 

if 1 S i S n 
X if i > n 
X 



where i is a positive integer. 
45 The factor operator is a binary operator that is defined 
over lists and bags as follows: 



I*(factor(S,Q) 




FACTOR(I-(S),['Q) 


FACrORQlb) 




D 




FACrOR(X,b) 




X 




FACTOR({},b) 




{} 




FACrOR([a„ . . 




I(a,b), . . 




FACrOR({at, . . 


• . a„}.b) 


{(ai,b), . 


■ - >Can,b)} 
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The map operator is an operator that is defined over lists 
and bags follows: 



I'(mapCf)(S) 




I*MAPCfJ*(S)) 






[] 


MAP(/,{}) 




0 


MAPCfJ.) 






MAPCf^at, . . 




lP(/(a,)), . . . , I'C/CaJ)] 


MAP(jf,{ai, . . 




(I-CfCaO). . . . , I-Cf(0)} 



Where / is any CPL function with only one input parameter. 
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The collect operator is recursively defined over lists and 
bags as follows: 



f(Collect(ide,e)CS)) 
COLLECrai, ide,e) 
COLLECr({}.ide,0) 
COLLECr([al, ide,e) 
COIXECr({a},ida,e) 
COLLECr([ai,a2, . . . , aj 

C0LLECr({ai^2. ■ • • . ^i}* 
ide,e) 



-COLLECr*(I*(S), ide,9) 

-ide 

-ide 



I-(e(ai, C0LLECr({a2 , . . . » a^}. ids.6)) 



0 




U (Union) 


{T} 


@ (concat) 


[T] 


or 


Boolean 


and 


Boolean 


+ 


integer 




integer 


* 


integer 


sup 


atom 



o • cd:ti — (tiuc,falsc}, o • S,: {tj} 

where t^ is any CPL type. sclect(cd)(Sj) returns a subset R 
of elements of Sj. An elcmcDt e^ of Sj is in R if cd(e^)=true. 

The select(cd) operator (on bags) is equivalent to the 
following sequence of CPL statements: 



cond(cd) : : - X -» if cd(x) then {X} else {} 

select (cd) : : - S collect ({}, U)(map(cond(cd))(S)) 
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The U collector computes the (bag) union of two bags 
(double are not eliminated). The @ collector does the 
• concatenation of two lists (©([a^, , . . , a„], [bj, . . . , b^^J^ 
[aj, . . . a„, bj, . . . , bj). 

In practice, the user can define new collectors either (i) by 
providing built-in collectors associated with built-in atom 
types, or (ii) by constructing new collectors using the CPL 
language. Indeed, the CPL language permits the user to 
declare any binary function to be used as a collector. 

Constructed operators will now be defined. A constructed 
operator is an operator which is equivalent to a sequence of 
CPL statements. A constructed operator can always be 
defined using basic operators. Constructed operators are 45 
used in CPL as a short-hand to represent sequences of CPL 
statements that are frequently used in CPL programs. 
Select Operator 

The select operator is an operator that is a parameterized 
by a boolean CPL function. It applies on lists or bags. The 
typing rules for select are: 
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The select(cd) operator (on lists) is equivalent to the 
following sequence of CPL statements: 
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ooudCcd) : : - X — if cd(x) then {X} else [] 

select (cd) : : - L collect (Il@)(map(cond(cd))(L)) 



Join Operator 

The join operator is binary operator that is a parameter- 
ized by a boolean CPL function. The typing rules for join 
are: 

a-t-cd: n -» itiuc. false), crh^i: {fi}. cri-Si: {/il 



where 0 is a collector. A collector is a complete binary 15 
operator with identity idg. A collector can be any fiinction 
TxT-*T where T is any CPL type except an atomic mapping 
type. The table below gives the predefined collectors that are 
used in the CPL. 

20 
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0-1- join(cif)(S,, ^2): {{f_a: fi. s_a: /2)) 

a-t-cd: ti -» {true, false), ck^j: [n], (rt-Sz: [/i] 
trh join(crf)(5i, ((f_a: fj, 8_a: fj)) 



where tj and I2 are any CPL type, join (cd) (Sj, S^) returns 
a set R of tuples of the form <j^__a:ti, s_a: t2>. A tuple <e^, 
e2> is in R if Cj is in S^, 62 is in and cd(ei, C2)=truc. 

Join (cd) is equivalent to the following sequence of CPL 
statements: 
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cond(cd) 

inncr_loop(cd) 

Join(cd) 



: ; - X -* cd(x./_a, x.8_a) 
: : - y select(cond(cd))(facior(y.s_a,y.f_a)) 
: : - SjjSj -* collect ({),U)(inap(inner_loop(cd)) 
(factor(S2, SO) 



Trans Operator 

The trans operator is a binary operator that is parameter- 
ized by CPL function. The typing rules for trans are: 

a-i- f: ft -> r3. cri-^i: {fi). crhfa: h 
crl-trans(/)(5,, cj): Us) 

£rKtrans(/)(5i. ei): [ti] 



trans (f) is equivalent to the following sequence of CPL 
statements: 



g(f) 

Trans (£) 



X (s.j'_apc.s_a) 

S,y - map(gCf))(factor(S,y)) 



Enum Operator 

The enum operator associates each element of a list with 
its position in the list. The typing rule for trans is: 



o-t-Li: [ri] 
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cr (- enum(Li ): [{pos: int, val\ t\j) 



It is defined as follows: 



I*(enum(e,) 


ENUM(I''(eJ) 




ENUM(ai, . . . 


{<pos : 1, val : ai>, . . 


. , <poa : k, val : ti^>\ 








ENUMaD 


- [] 




ENUM(l) 


± 
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The enum operator is equivalent to the following 
sequence of CPL statements: 
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rcv_concat 
reverse 
init_enuin 
mcrgc_enuin 

cmirn 



: - li. I2 - la @ ii 

: - collect Q], rev_concat)(inapOistmg)Oi)) 

: - X [<pos : IjVal : x>] 

: «" li, L2 (<pos Ji^fO.pos +Lz#0.pos,val : 

l,i¥0.val>]@L3> 
: = L rcvciw;(collcct(Il mcrgc_caum)([iiap(iDit_ 

enuinXrcveise(L)))) 



10 



Dot Operator 

The dot operator is a binary operator that combines two 
lists by associating elements with same position. The typing 
rule for dot is: 

o-hL,: [tiltn-Li-. [T2I 



18 

-continued 

trhgroup(5): {(hask f \ vals: [f])] 



where t* is an atom type. 

Group takes as input a bag (resp, a list) and produces as 
output a bag of tuples of the form (h„S,-) iel . . . n such that 

Vijel . . . n, (h,-pshy)or(i=j) and, 

Each member s,- of S,- contains the projection on the 
second attribute of all the tuples in S whose first 
attribute is equal to h,. 
The Group Operator is equivalent to the following 
sequence of CPL statements: 
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cr hdot(Li, Lz): [{f_a fj, »_a: /j)] 



It is defined as follows: 



20 









- DOTa*(cO,I'(62)) 




LfOc<n): 










DOT([ai, . . . 






- [<f_a : ai,s_a : bi>, . . . 

ak^_? : 

bi(>,<:f_a : 

l,s_a: ^ 

<C_a : l^_a: b„>] 




Lf(k>n): 










DOT([a„ . . . 






- (<f_a : ai,6_a : bi>, . . . 

a : b„>,<f_a„4.i,5_a 
: J.>, 

<{_& : ajj^_a:J.>] 


,<La: 


if (k-n) : 










DOT([ai, . . . 


» aitl [bl, . 




" [<f_a : ai,s_a : bi>, . . . 
a : b^, 


,<Ca : 


DOT([a„ . . . 






0 [<f_a : ai,s_a : X>,<f_a 
:1>] 


: ak,s_a 


DOT(Xjb,, . 






- [<f_a : l^_a : bi>,<f_B 


: -L^_a : 


DOT(X,J.)-X 











n(hash) 

tcst_eq 

I s_m 

add_to_scl 

climin_doublc 

same_Jush 

all_same_hafih 
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Group 



The dot operator is equivalent to the following sequence 
of CPL statements: 



to_one 




X - 1 


count 




L collcct(0,'+)(map(to_oiicpc)) 


choose__fiist 




x,y X 


first 




L -• collect(l,choose_fir8t)(L) 


cd 




X x.f.a.pos = x.s__a.pos 


6ame_po6 




X -» <£_a:x.f_a.val;s_a: 

(first(sclcct(cd) (factor(x.6_a ^.f_a)))). f_a.val> 






rev_ 




X -» <f_a: (ftisi(select(cd)(factor(x.s_a^.f_a)))). 


same__poB 




f_aval; s_a : x.f_a.val> 


dot 




Li.L^ if couat(Li) >- count (Lj) then 
map(same_pos)(factor(enum(L,), enum(L2))) 
else map(rcv_sam&_pos) (f actoi(cnum(L2),cnum 



Group Operator 

The group operator is a parameterized operator. The 
typing rules for group are: 



(Ti-S: {{hask i*; vat t)) 
(rKgroup(^): {{hask f \ voir [t*))) 



S inap(pioj(hash))(S) 

X if x.f.a = x.s_a then true else false 

x,S — coUect(false, or)(inap(test_eq)(factor(Spt))) 

fi.S -* if I s_ii(umtval(s),S) then S else s U S 

S collcct({},add_to_BcO(map(bagging)(S)) 

S -* climin.doublc(j((hash)CS)) 

X -* if x.f„a.hash = i.s_a then {x.f_a.val} else 

y — {bash: 

y.Oi,vals:collcct({}, U)(map(sainc__hash)(£actor 
(y.s_a,y.f_a)))>} 

S collcct({},U(map(all_5amc_Jia5h)(£actor(jt 
(hash)(S),S))) 



Sort Operator 

TTie sort operator is a parameterized operator. The typing 
rules for sort are: 



cr k a: / X f -> fTiue. False), tr h 5: {/) 
cr h soit(af)(^): [/] 

trf-a: /Xf frnic,Falsc), crl-5: [f] 
cr h soit(a)(5'): [/] 
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where a is a CS mapping that describes an order relation 
over values of type T More precisely, a is a CS mapping that 
takes as input two values of type T and returns a boolean 
value, a returns the value True if the first argument is greater 
than the second argument and False otherwise, a describes 
45 a non-strict order relation if it verifies the properties (1) (2) 
and (3) described below, a describes a strict order relation if 
it verifies the properties (1) and (4). 



(X\ if (a(x,>0 and (a(y,z) then a(x,z) 
(2) a(: 
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.(x,x)-True 

notfafcy^) or rnotrary,xJ) or (y=x)) 
4) not(a(x,y)) or (not(a(y,x)) 

The sort operator performs as follows: sort(a)(S) sorts the 
value of S in an increasing order according to a. Let us note 
that the result is not deterministic since (i) the order relation 
a is applied on a bag and (ii) a may define a partial order. 

The sort operator is equivalent to the following sequence 
of CPL statements: 





::>» X a(x.s_a,x.f_a) 


stlcct_in/ 


::«> y^ — 56lcct(f(a)){£actor(Ly)) 


select__ncl^_in / 


y^ -* Kelect(ttOtCf(a)))(£actoiOLy)) 


merge_oKier 


::- 1,L -* 8elect_in J(l#0, L)@l@select_not_Jn 




/(l#0, L) 

:> S -* ccnect(Ilmerge_ordcr)(map(listing)(S)) 


sort(a) 
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The foregoing was a formal definition of the CPL lan- 
guage. Examples of how the language is used to implement 
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combining policy will be given below in connection with the 
ongoing example. 

Returning now to the description of the example appli- 
cation and FIG. 2, module 260 is specified in terms of 
computation rules and a combining policy, and is shown 
textuaUy in FIG. U. The computation rules arc specified in 
line 25-39 of the DL specification. As defined in lines 
21-22, the output attribute WAP_UP is a set of mples 
containing an attribute name and a value of the attribute. In 
effect, this attribute contains various attribute names and 
associated values for archival purposes. The first three rules 
(hues 26-31) are of the form "if true", so that they will 
always be True, and the values specified in those rules will 
always contribute to the attribute WRAP_UP. The compu- 
tation rule on lines 32-35 will only contribute to the attribute 
\VRAP_UP if the attribute WEB_DEST[NAnONS is not 
empty. Similarly, the computation rule on lines 36-39 will 
only conuibule to the attribute WRAP_UP if the value of 
CUST_REC.CARD_COLOR is "gold". The combining 
policy (wrap-up-cp) is specified in lines 40-41 and indicates 
that the contribution of all true rules are to be used. It is 
assumed that this combining policy is a predefined CPL 
function which is available for use by system designers. The 
CPL program defining this function is as follows: 

wrap_up_cp::-x->select (value) (x) 

It is also noted that the Calculate_Wrap_Up module 260 
has a side-effect, as specified in line 42. The side-effect of 
this module is to use the WRAP_UP attribute to write into 
an archive. This archive may be, for example, an external 
database which stores operational information for the sys- 
tem. 

Returning now to FIG. 2, module 220 will be described in 
further detail As described above in conjunction with FIG. 
5, module 220 contains 8 sub-modules 504, 508, 512, 516, 
520, 524, 528, 532. Modules 504, 508, and 512 arc modules 
which perform database retrievals in order to assign values 
to attributes. The DL specification for the Get_Recent__ 
Contacts_For_This_Customer module 504 is shown in 
FIG. 12. Based on the input attribute ACCOUNT_ 
NUMBER, the module wiU perform a database query as 
specified in lines 13-16 in order to evaluate and assign a 
value to the output attribute RECENT_CONTACTS. The 
DL specification for the Get_Recent __Purchases_For_ 
This_Customer module 508 is shown in FIG. 13. Based on 
the input attribute ACCOUNT„NUMBER, the module will 
perform a database query as specified in lines 10-13 in order 
to evaluate and assign a value to the output attribute 
RECENT_PURCHASES. The DL specification for the 
Get__Account_Jlistory_J'or_This_Customer module 512 
is shown in FIG. 14. Based on the input attribute 
ACCOUNT ^NUMBER, the module will perform a data- 
base query as specified in lines 14-17 in order to evaluate 
and assign a value to the output attribute ACCOUNT_ 
HISTORY. 

Returning now to FIG. 5, the Calculate Jrustration_ 
Score module 516 is represented as a hexagon, which 
indicates that the module is a decision module and that the 
processing of the module is specified in terms of computa- 
tion rules and a combining policy. The DL specification for 
this modudc is shown in FIG. 15. The computation rules are 
shown in part in lines 7-19. There would likely be additional 
computation rules, but such rules are not shown because 
they are not necessary for an understanding of the relevant 
portions of FIG. 15. The input attribute to this module is 
RECENT__CONTACTS, which is a list as defined in FIG. 
12, lines 4-10, Thus, the computation rule specified in lines 
8-13 of FIG. 15 specifies that if the attribute RECENT_ 
CONTACTS is defined for list element [1] (i.e., there is at 
least one recent contact specified in the RECENT_ 
CONTACTS attribute), then the expression in lines 10-13 is 
evaluated and the result is contributed to the 



)9,023 Bl 

20 

FRUSTRATION_SCORE attribute. Similarly, the compu- 
tation rule specified in lines 14-19 of FIG. 15 specifies that 
if the aUribute RECENT_CONTACTS is defined for list 
element [2] (i.e., there are at least two recent contacts 
5 specified in the RECENT_CONTACrS attribute), then the 
expression in lines 16-19 is evaluated and the result is 
contributed to the FRUSTRATION'S CORE attribute. 
Additional computation rules would likely be included in an 
actual implementation, but are not shown here. It is noted 
that in this example, any or all of the computation rules may 
evaluate to True, in which case the attribute 
FRUSTRAnON_SCORE gets contributions from each of 
the true rules. 

The combining policy for the CaIculate_Frustration_ 
Score module 516 is a CPL function, frtistradon-score-cp, as 
15 specified in lines 21-24 and indicates that the contributions 
of the true rules will be added together and rounded up to the 
next integer, up to a maximum of 10, The result is assigned 
to the attribute FRUSTRAnON_SCORE. The CPL pro- 
gram defining this function is as follows: 
20 Calcidate_Frustration_Score ( 

sum_true x -> collect (select(value), 0 , +) 
min__of ::- X, V -> if X > V then v else x 
Frustratioo_scorc_cp cont_vals -> min_of (rounds 
up(sum_true(cont_vals,l)) , 10) 
^ The Calculate _Net_Profit_Score module 520 (FIG. 5) is 
represented as a hexagon, which indicates that this module 
is a decision module and that the processing of the module 
is specified using computation rules and a combining policy. 
The DL specification for this module is shown in FIG. 16, 
30 The computation rules are shown in lines 10-32. The input 
attributes to this module are RECENT_CONTACTS, 
RECENT_PURCHASES, ACC0UNT_J1IST0RY, and 
CUST_REC. The computation rules specified in lines 
10-32 specify the contributions to the attribute NET_ 
35 PROFIT_SCORE based on the input attributes. The com- 
bining policy specified in lines 33—35 is a CPL function, 
net-profit-score-cp, and indicates that the contributions of 
the true rules wiU be added together. The resulting sum is 
assigned to the attribute Net _J'rofit__Score. The CPL pro- 
4Q gram defining this function is as follows: 

Net_Profit_Score_cp ::- cont_vals -> sum_true(cont__ 
vals) 

The Calculate_Late_Payment_Score module 524 (FIG. 
5) is specified using computation rules and a combining 
policy and the DL specification for this module is shown in 
FIG. 17. The computation rules specified in fines 7-19 
specify the contributions to the LATE_PAYMENT_ 
SCORE attribute based on the input attribute. The combin- 
ing policy as specified in fines 20-22 is a CPL function, 
late-payment-score-cp, and indicates, that the contribution 
of a true rule will be assigned to the attribute LATE_ 
PAYMENT_SCORE, or if there is no rule evaluating to a 
true value, then the LATE JAYMENT_SCORE attribute 
will be assigned the default value of 0. It is noted that a 
constraint on this type of combining policy is that only one 

55 computation rule may evaluate to true. This constraint could 
be tested for during a pre-processing step to make sure that 
any possible evaluation will result in only one computation 
rule being true. The CPL program defining this function is 
as follows: 

60 choose„first x,y -> x 

Late_Payment_Score__cp ::« cont_vals -> collect(0, 

choose _flrst)(select(value)(cont_vals)) 
The Calculate_Cust_Value module 528 ^IG. 5) is speci- 
fied using computation rules and a combining policy and the 

65 DL specification for this module is shown in FIG, 18. The 
computation rules specified in lines 9-19 specify the con- 
tributions to the CUST_VALUE attribute based on the input 
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attributes. The combining policy as specified in lines 20-23 
Ls a CPL function, calculatc-cust-val-cp, and indicates that 
the contributions of rules with a true condition are added and 
rounded up, with a maximxim of 100. The result is assigned 
to the attribute CUST_VALUE. If no rule evaluates to a true 5 
valve, then the CUST_VALUE attribute is assigned the 
default value 0. The CPL program defining this function is 
as follows: 

Calculate_cust_Value_cp ::- cont_vals -> miQ_of 
(round_up(sum_true(cont_vals)),100) 10 

The CalcuIate_Marketing_vs._Collections module 532 
(FIG. 5) is specified usiog computation rules and a combin- 
ing policy and the DL specification for this module is shown 
in FIG. 19. The computation rule specified in fines 8-16 
specifies the contributions to the MARKETING_VS_ 15 
COLLECTIONS attribute based on the input attributes. It is 
noted that in an actual implementation additional rules 
would likely be included. The combining policy as specified 
in lines 19-24 is a CPL function, marketing-vs-coUection- 
cp, and indicates that the contribution of a true rule will be 20 
assigned to the attribute MARKETING_VS_ 
COLLECTIONS, or if there is no rule evaluating to a true 
value, then the MARKETING_VS_COLLECTIONS 
attribute will be assigned the default value "marketing". In 
this module, it is assumed that all computation rules (not all 25 
shown) have the effect of contributing the value "collect", 
and so there is no inconsistency if more than one rule has a 
true condition. The CPL program defining this function is as 
follows: 

marketing_vs_collection_cp ::= cont_vals -> collect 
("marketing" ,choose_first) (select (value) (cont_vals)) 
Returning now to FIG. 2, module 250 will be described in 
further detail As described above in conjimction with FIG. 
9, module 250 contains 6 sub-modules. The Ask__Reason_ 
For_Call module 910 wiU be evaluated if the COST 
VALUE attribute has a value less than 7, as indicated by 
enabling condition 912. Module 910 is represented as a 
rectangle, which indicates that the module is a foreign 
module. Module 910 requires an IVR interaction and asks 
the caller the reason for calling. The reason is assigned to 40 
attribute IVR_CHOICE. The DL textual specification for 
module 910 is show in FIG. 20. The computation steps are 
set forth in lines 8-12, which indicate that the attribute 
I VR_CHOICE will be assigned the value "dom'' or "inU" or 
the state of this attribute will be EXCEPTION with an 45 
exccptioD_value of 1, depending on the response to the IVR 
question. This module has a side-effect, as indicated in lines 
14—15. The side effect is an IVR_dip, which will initiate an 
IVR question to the caller using the external IVR component 
112 (FIG. 1). 50 

Module 920 is represented as a hexagon, which indicates 
that this module is a decision module and is specified using 
computation rules and a combining policy. The DL specifi- 
cation for module 920 is shown in FIG. 21. The computation 
rules specified in lines 12-30 specify the contributions to the ss 
BUSINESS_VALUE_OF_CALL attribute based on the 
input attributes. The combining policy as specified in lines 
31-34 is a CPL function, business-value-of-call-cp, and 
indicates that the contribution of the rules with a true 
condition are added and rounded up with a default value of eo 
0. The CPL program defining this function is as follows: 

Business_Value_of_Call_cp ::=» cont_vals -> round 

up(suin_true(cont_vals)) 
The DL specification for the Calculate_Send_Bonus_ 
Check module 930 is shown in FIG. 22. This module is 65 
represented as a rectangle, which indicates that this is a 
foreign module. This module will only be evaluated if the 
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enabling condition specified in lines 5-13 is True. In such 
case, the module performs the side-effect action of issuing a 
check to a customer as specified in lines 16-17. 

As shown in FIG. 9, all remaining sub-modules of the 
Rouling_Decisions module 250 are represented as 
hexagons, which indicates that these modtiles are decision 
modules and are specified using computation rules and a 
combining poUcy. T\iming now to the Calculate_Call_ 
Priority module 940 module, the DL specification for this 
module is shown in FIG. 23. The computation rules specified 
in lines 8-20 ^ecify the contributions to the CALL_ 
PRIORITY attribute based on the input attributes. The 
combining policy as specified in lines 21-22 is a CPL 
function, call-priority-cp, and indicates that high value wins 
with a dcfaidt value of 2. This means that the single highest 
contribution value for a true rule is the value that is assigned 
to the CALL_PRIORITY attribute. Thus, after all the 
computation rules are evaluated, there will be a collection of 
all the results, with the true rules contributing the value 
specified in the rule, and the false rules contributing J_. The 
combining policy will choose the highest value in the 
collection and assign that value to the output attribute 
CALL_PRIORITY. If no rule has a true condition, then the 
value of 2 is assigned to CALL_PRIORITY. The CPL 
program defining this function is as follows: 

choose_sup ::=x,y -> if (x >= y) then x else y; 

CaU__Priority_cp ::= cont_vals -> coUect(2<choose_ 
sup) (select(value)(cont_vals) 
The DL specification for the Calculate__Skill module 950 is 
shown in FIG. 24. The computation rules specified in lines 
11-40 specify the contributions to the SKILL attribute based 
on the input attributes. The combining policy as specified in 
lines 41-45 is a CPL function, skill_cp, and indicates a 
weighted sum policy with ties being broken by the given 
ordering. Referring back to the computation rules, each true 
rule will contribute both a value and a weight to the SKILL 
attribute. For example, if the computation rule on lines 
14—15 is evaluated to True, then the value high__tier with a 
weight of 40 is contributed to the SKILL attribute. After all 
the computation rules are evaluated, the sum of each of the 
weights for a particular value is computed, and the value that 
has the greatest weight is assigned to the SKILL attribute. If 
there is a tie between the weights of two different values, the 
value assigned to the SKILL attribute is determined by the 
ordering given by the combining policy. As an example, 
suppose the computation rule in line 28 and the computation 
rule in lines 32-35 are both evaluated to true. The compu- 
tation rule in line 28 will contribute the value norm ticr_ 

dom with a value of 30, and the computation mle in lines 
32-35 will contribute the value norm_tier_dom with a 
value of 20. If these were the only two rules which contrib- 
uted weights to the value norm tier__dom, then the value 

norm-tier_dom would have a combined weight of 50 (30+ 
20) when the combining poUcy was evaluated. If this 
combined weight of 50 for the value norm_tier_dom was 
the highest combined weight of any value, then the value 
norm__tier_dom would be assigned to the output attribute 
SKILL. The CPL program defining this function is as 
follows: 

aggval X -> tup ling (hash;« x.hash; val :« sum_truc 
(x,vals,0)) 

complist ::= [" collections" australia_promo" , " high_ 
tier" , " low„tier_intl" low_tier_down" ] 

ccomplist ::- enum (complist) 

compsel ::« X -> x.f_a.val = x.s_a 

poslist ;:= x -> (select(compsel)(factor(ccomplist,x)) 
/«).f_a.pos 
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compval x,y -> if (x,val > y.val) then x 
else if y.val > x.val then y 
elseif poslist(x) < poslist(y) then x else y 

SkilL_cp :: = cont_vals -> collect(NULL, compval) (map 
(aggval) (group(cont_vals))) 

The DL specification for the Calculate_On_Queue_ 
Promo module 960 is shown in FIG. 25. The computation 
rules specified in lines 8-13 specify the contributions to the 
ON_QUEUE_PROMO attribute based on the input 
attribute. The combining policy as specified in lines 14-15 
is a CPL function, on-queue-promo-cp, and indicates first 
true wins with a default of 0. In accordance with this 
combining policy, the contribution of the true rule will be 
assigned to the attribute 0N_QUEUE_PR0MO. As 
described above, a constraint on this type of combining 
policy is that one and only one computation rule may 
evaluate to true. The CPL program defining this function is 
as follows: 

on_Queue_Promo_cp ::= cont_vals -> collect (NULL, 
choose_first)(select(value)(cont_vals)) 

Returning to FIG. 1, the above description described the 
DL specification 102. We now turn to a description of the 
decision engine 104 which will take the DL specification 
102 and implement the specified workflow when an object 
(e.g., incoming call) is received at the workflow system 100. 
The following description will describe two embodiments of 
a decision engine 104. The first embodiment implements a 
straightforward execution of the workflow. The second 
embodiment implements an improved workflow execution 
which utihzes optimization strategies. 

The first embodiment of the decision engine 104 requires 
that a topological sort of the modules be created. In order to 
describe the topological sort, first the data and enabling flow 
diagram shown in FIG. 26 will be described. This diagram 
illustrates the data flow dependencies and the enabling flow 
dependencies of the workflow described above. Each of the 
modules (ovals) and enabling conditions (hexagons) are 
represented as nodes with solid line data flow edges repre- 
senting data flow dependencies and broken line enabling 
flow edges representing enabling flow dependencies. Node 
2601 represents the source attributes. A data flow edge from 
a module M to a module M' indicates that an output attribtite 
of M is used as an input attribute of M'. An enabling flow 
edge from a module M to the enabfing condition of a module 
M' indicates that the enabling condition of M' uses an output 
attribute from M. Also, there is an enabling flow edge from 
each enabling condition to the module that it qualifies. For 
example, there is a data flow edge 2602 from the identify 
caller module 2604 to the info_about_customer module 
2606 because the input attributes ACCOUNT_NUMBER 
and CUST_REC of the info_about_customer module 
2606 are output atU-ibutes of the identify_caller module 
2604. There is an enabling flow edge 2608 from the 
identify_caller module 2604 to the enabUng condition 2610 
of the info_about_customer module 2606 because the 
attribute ACCOUNT_J>njMBER used in the enabling con- 
dition 2610 is an output attribute of the identify_caller 
module 2604. There is an enabling flow edge 2612 from 
enabling condition 2610 to the module 2606 which it 
qualifies. Thus, FIG. 26 shows the data flow and enabling 

flow dependencies for the routing to_skill module 202 

(FIG. 2). The data flow and enabling flow dependencies for 
lower level modules could similariy be shown using data 
and enabling flow diagrams. It is noted that the data and 
enabUng flow diagrams of the modules are acyclic. That is, 
there is no module M for which there is a directed path in the 
graph composed of data flow and control flow edges that 
starts at M and ends at M. 
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The first step of the decision engine 104 is to produce a 
topological sort of the modules in the workflow description. 
As is well known, a topological sort is an ordering of 
modules such that the ordering satisfies the following prop- 
5 crtics: 

If module M precedes module M* in the ordering then: 
there is no directed path in the graph composed of data 

flow edges and enabling flow edges that starts at M' and 

ends at M. 

10 Given the notation shown in FIG. 26, one topological sort 
for the modules shown in FIG. 26 is Mj, Mj, M3, M4, Mj, 
Mg. Topological sorts for lower level modules would be 
produced in a similar manner. After determining the topo- 
. logical sort, the modules may be executed such that a 
15 module is executed only after all preceding modules in the 
topological sort are completely finished executing and all 
attributes have been evaluated. Thus, given an ordering M^, 
M2, . . . Mjv, the modules are executed as follows: 

enabling condition of is evaluated and if True, then 
^ module is completely executed, if False, then 
module is not executed; 
enabUng condition of M2 is evaluated and if True, then 
module is completely executed, if False, then 
module is not executed; 
^ enabling condition of is evaluated and if True, then 
module is completely executed, if False, then 
module is not executed. 
The above steps describe how a determination is made as to 
whether a module will be executed. With respect to how a 
module is executed, it depends on the type of module. If the 
module is other than a decision module and therefore 
specified in terms other than computation rules and a com- 
bining policy, then the module is executed as specified in the 
module (e.g. C++ program, database dips flowchart, declara- 
tive module, etc.), and the details of such execution will not 
be described in detail herein. If the module is a decision 
module specified in terms of computation rules and a 
combining pohcy, then the module is executed as follows: 
^ for each computation rale 

test the condition for True or False 
If False, produce 1 and add to collection 
If True, then compute the value of the term on the 
right side of the rule and add to collection. 
45 (** at this point have a coUection of values and/or ±**) 
apply combining policy program to the collection of 

values to produce the attribute value 
assign attribute value to the attribute; 
execute any side -effect, if any. 
50 The above described embodiment of the decision engine 
104 executes the DL specification in a straightforward 
manner That is, the various modules are executed sequen- 
tially in a topological order. However, the use of a more 
sophisticated execution technique can result in improved 
55 performance of the system. Such an execution technique 
will now be described. 

For clarity of exposition, the more sophisticated execution 
technique for executing declarative modules will be 
described in a simplified context, but one skiUed in the art 
60 will be able to extend the description presented here so that 
it can be used on arbitrary declarative modules. In the 
simplified context, the focus is on a DL program that 
consists of a declarative module with one or more internal 
modules. It is further assumed that each internal module 
65 computes exactly one attribute, and may have a side -e fife ct. 
It is further assumed that once enabled, internal modules will 
always produce a value and will never produce an exception 
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value. Because each internal module produces only one The prequalificr 2804 will determine three key properties 
attribute, a single state can be used for an attribute and the of tasks which substantially improves the performance of the 
module that produces it. The states for attributes (modules) decision engine 104. Tasks which arc eligible for eager 
in this context are {UNINITIALIZED, VALUE, DIS- evaluation are tasks which may be immediately evaluated, 
ABLED}. Finally, suppose that module M produces 5 but which may or may not be required for complete pro- 
attribute A, Because A is the only attribute produced by M, cessing of the workflow instance for a given object It is 
for convenience in exposition we refer to attribute A as a noted that immediate execution of an eligible task will not 
side-effect attribute if M is a side -effect module. Similarly, violate the intended meaning of the DL specification. Tasks 
we refer to attribute A as a non-side-cffcct attribute if M is which are unnecded are tasks which are not needed for 
a non-side-effect module. ,10 coniplcte processing of the workflow instance for a given 

When describing the more sophisticated execution object. Tasks which arc necessary are tasks which are knovvTi 
technique, the term task is used to refer to an execution of be needed for complete processing of the workflow 
a module during execution of an instance of the workflow. instance for a given object. By using these three character- 
Thus, a task refers to the activity (actual or potential) of -^^-^ decision engine 104 can substantially 
cxecutmg a module^ ^^'^J'^^ described below, m some ^ performance. Tasks which arc eUgible but 
cases a task wiU be identified but no earned out For 15 ^^eded may be deleted from the candidate task pool 2802, 
example, a module and mput values for It may be identified .,1 . v -.i j t_ ■ 
as eligible for execution but subsequeoUy be deemed and tasks which are eligible and necessary may be given 
unneeded for completing the workflow and thus not high.prionty because it is known that these tasks will be 

executed. A task is a side-effect task if the module under- required for complete prooessmg 

lying the task is a side-effect module. A task is a non-side- 20 Algorithms for dctermmmg whether tasks are eligible, 

effect task if the module underlying the task is a non-side- unnecded, or necessary will be described below. Because of 

effect module the complexity of the algorithms, the description v^ll pro- 

A high level functional diagram of the decision engine ^ steps. First, an algorithm, identified as the basic 

104 is shown in FIG. 28. The oval components represent algorithm, for determining whether tasks are eligible or 

data repositories and the rectangles represent software mod- 25 unnecded v^l be dcscnbed. Thereafter, an extension to the 

ules. The workflow schema 2810 represents the specification ^^^^ algorithm, identified as the extended algorithm, for 

of how workflows are to be processed. For example, the ^^^her determining whether tasks are necessary wiU be 

workflow schema may be a DL specification as described described. 

above. Whenever a new object to be worked on is received ^o describe the algonthms, several definitions 

(e.g. a new caU enters a call center), a new instance of the 30 "^^^t be introduced. For purposes of this description, assume 

workflow is created and stored in runtime workflow that a workflow schema S=(Att, Src, Tgt, Eff, Cnd, Mod) is 

instances 2808. The execution engine 2812 works on a schema provides a mathematical formalism for 

runtime workflow instance stored in 2808 in accordance describmg DL specifications of declaraUve modules. The 

with the workflow schema 2810 to execute the tasks in the elements of the schema S are as follows: 

workflow and to propagate the effects of the execution until 35 Att is a set of attributes; 

the object has been fully processed. The execution engine Src is the set of source attributes; 

2812 works in a multi-thread fashion, so that it processes in Tgt is the set of target attributes; 

parallel multiple workflow instances and multiple tasks Eff is the set of side-effect modules; 

within each instance. The task scheduler 2806 schedules the Cnd is the set of enabling conditions; and 

tasks that will be executed by the execution engine 2812. 40 j^q^j jg modules. 

The task scheduler 2806 dynamicaUy chooses the tasks to be R^^all that in the simphfied context, each module pro- 
executed from the candidate task pool 2802, which is duces as output a single non-source attribute. The algorithms 
maintained by the prequalifier 2804. described here focus on deteraiining sets of attributes that 

The decision engine 104 executes tasks m an eager ^re eUgible, unneeded, or necessary. We also apply these 

fashion, that is, the decision engine 104 will use available 45 tenns to the modules associated with attributes, and to the 

computing resources to execute tasks prior to fully deter- tasks associated with those modules. For example, if 

mining whether such tasks are required for processing the attribute A is found to be eligible in the context of an 

workflow instance for a given object. Such speculative execution of a workflow instance, then we also say that the 

execution generaUy improves the performance of the system ^^^^i^ ^ defines Ais eUgible in that context. Further, 

by reducmg the response time (i.e., the time it takes to 50 ^ask T of executing module M (whether this execution 

process inputs to the system) because computing resources ^^^c^j^ not) is said to be eligible in that context. 

wiU be fully uUlized. Of course, by eager execution of tasks, Q^^er to implement the basic algorithm, additional 

certain tasks will be executed unnecessarily. However, the grates (i.e., in addition to those described above) for 

overall performance will be improved by eagerly executing attributes must be defined. The states used in the algorithm 

certain tasks which, in fact, are needed to fully process the 55 ^j-g. 

workflow instance. UNINITIAUZED 

The presence of side -effect modules imposes an important ENABLED 

restriction on the eager evaluation of tasks. In particular, in pp ahv 

a workflow instance a side-effect module should not be KLAJJY 

executed eagerly unless it is known that the module would 60 READY+ENABLED 

also be executed in accordance with the declarative meaning COMPUTED 

of the DL specification. This restriction is motivated by the VALUE 

assumption that the processing impact of executing a side- DISABLED. 

effect module is so significant that the possible benefit of It is noted that the states EXCEPTION, and FAIL were 
eager execution of the module is outweighed by the desire 65 defined above as attribute states, but are not used in con- 
to avoid execution that is not justified by the meaning of the junction with the simplified context for describing the 
DL specification. execution algorithm. 
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In the context of the execution of a workflow instance, the 
states for an attribute A are defined as follows. Initially, an 
attribute A will be in the state U>aNlTIAUZED. This 
indicates that the attribute A has not yet been considered in 
the execution. The state ENABLED indicates that it has 
been determined that A's enabling condition is, or will 
eventually be, True, but it is not yet determined whether A's 
input attributes are stable (i.e., the input attributes are in the 
state "value"' or "disabled"), and the value for A has not yet 
been computed. The READY state indicates that the input 
attributes for A arc stable, but no determination has been 
made as to whether A's enabling condition is true or false, 
and the value of A has not been computed. The stale of 
READY+ENABLED indicates that the input attributes for A 
are stable and the enabling condition for A is true, but the 
value for A has not been computed. The state COMPUTED 
indicates that the value for A has been computed but it has 
not been determined whether the enabling condition for A is 
true or false. The state DISABLED indicates that the 
enabling condition for A is, or will eventually be, false. The 
state VALUE indicates that the value for A has been com- 
puted and the enabling condition for A is, or eventually will 
be, true. 

FIGS. 29 and 30 show the finite state automata (FSA) for 
this extended family of states. FIG. 29 shows the FSA for a 
noa-side-effect attribute, and FIG. 30 shows the FSA for a 
side-effect attribute. The difference between the FSA for a 
non-side effect attribute (FIG. 29) and a side-effect attribute 
(FIG. 3D) is that for side-effect attributes, the COMPUTED 
state is omitted. This is because, since the execution of 
modules computing side-effect attributes has significant 
impact on a system or user that is extemal to the workflow 
system, such modules should not be executed until it is 
kiiowo that their enabling conditions are, or eventually v^ll 
be, true. For example, it would be undesirable to initiate an 
IVR side -effect which asks a caller to provide certain 
information if that information is not required for complete 
processing of the object. The states VALUE and DIS- 
ABLED are represented in FIGS. 29 and 30 with double 
lines to indicate that they are terminal states for the 
attributes. If an attribute is in a terminal state then that 
attribute is considered stable. 

The notion of a snapshot will now be described. Snap- 
shots are used to represent different stages in the execution 
of individual workflow instances. Let Att be a set of 
attributes with associated states. For each attribute A the type 
of A is denoted by t(A). A snapshot for Att is a pair s=(a/i) 
where 

1. the state mapping a is a total function from Att into 
{UNINITIALIZED, ENABLED, READY, READY+ 
ENABLED, COMPUTED, VALUE, DISABLED} 

2. The value mapping is a partial function from Att into 
U{t(A)|A e Att}, such that for each A, /^(A) is defined iff 
a(A)=VALUE or o(A)«COMPUTED. If ^A) is defined 
then /4(A) e t(A). 

Thus, a snapshot is a data structure which stores the state (a) 
of each attribute, and if the state of an attribute . is VALUE 
then the data structure also stores the value (a) of the 
attribute. The snapshot contains relevant information at a 
particular point during workflow execution. As execution of 
the workflow progresses, the snapshot will change to reflect 
the new information determined during execution. 

One snapshot s' extends another snapshot s (specified as 
s<s') if for each attribute A: 

(a) if A has a value in s, then A has the same value in s'; 
and 

(b) the state of A in s'^the state of A in s; 

where ^ is relative to the FSAs of FIGS. 29 and 30. Thus, 
criteria (b) means that the state of A in s' is equal to, or at a 
higher level in the FSA than, the state of A in s. 
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One snapshot s* strictly extends another snapshot s if for 
at least one attribute A, the state of A in s' is >the state of A 
in s. 

A snapshot s is complete if each attribute A in s is stable. 
That is, each attribute has a state of VALUE or DISABLED. 

For the purposes of describing the execution algorithm a 
particular formal definition for enabling conditions in DL 
specifications is now presented. One skilled in the art will be 
able to use the techniques described here in connection with 
DL specifications that use a different formalism for enabfing 
conditions and/or enabling conditions that can test values 
and properties different than those tested by the enabfing 
conditions presented here. 

A denotes attributes, term denotes terms, and pred denotes 
Boolean functions (such as comparison term 9 term) on 
terms which do not refer to states of attributes. The syntax 
of conditions is given by the following: 
cond pred(term, . . . ,term)| VALUE(A)| 

DlSABLED(A)|--cond|condAcond|cond vcond 
The tmth value of conditions is given by the standard 
two -valued logic when the involved attributes are stable, 
except that pred(ti, . . . ,tt) is true if all attributes referred to 
by pred(ti, . . . ytj^ have state VALUE and pred(ti, . . . , tj^is 
true in the standard sense, and it is false otherwise. Thus, 
when evaluating an expression, tf one or more of the 
attributes is in the state DISABLED, then the tmth value is 
false. Note that this logic does not always behave in the 
standard way (e.g. A>3vA^3 is not a tautology). The tmth 
value of a condition in a snapshot s where all attributes 
occurring in a condition y are stable, is denoted Tmth 
Val(Y,s). 

A complete snapshot is enabling-consistent if for each 
attribute A which is not a source attribute, the state of A is 
VALUE if and only if the truth value of the enabling 
condition of A relative to s is tme. 

A second notion of consistency concerns the relationship 
between the values of the attributes and the modules that 
define them. To provide an interpretation for the behavior of 
modules we define an environment for schema S to be a 
mapping e such that, for each module Min S^ if M has input 
attributes B^, . . . , B„ and output attribute A^ then e (M) is 
a total mapping from (T(B,)UJ.)x . . . xq(BJUl) to T(A). 
The use of a static environment in this formalism is a 
convenience for this description. In practice, DL workflows 
will operate in the context of a dynamic world, i.e., the 
environment associated with a given workflow instance may 
be the result of combining the behaviors of different modules 
at different points in time, rather than from a single point in 
time. 

A complete snapshot s is e-consistent for environment e if 
for each attribute A such that o(A) VALUE, yM(A) is equal to 
the A-value computed by e(M) (^B^), . . . , //(B J), where 
M is the module producing attribute A and has input 
attributes B^, . . . , B„. (Note that if B, does not have state 
VALUE in s for some i, then ;^B^=1.) 

An environment e is compatible with snapshot s if it 
agrees with all defined values of /an s. 

For a snapshot s, s\^^ denotes the snapshot whose state 
and value fimctions agree with those of s on all source 
attributes, and such that all non-source attributes have state 
UNINITIALIZED. 

A snapshot s over S is permissible if (i) there exists an 
environment e that is compatible with s, and (ii) for each 
environment e compatible with s, if s' is a complete snapshot 
that extends s[y^ and is compatible with a, then s' extends s 
and the set of side-effect modules with state in {ENABLED, 
ENABLED+READY, VALUE} in s is a subset of the set of 
side-effect modules with state VALUE in s'. 
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It is noted that the notioD of pennissible snapshot captures 
in an absolute sense the family of snapshots s such that all 
determinations in s concerning whether attributes arc 
ENABLED or DISABLED and all side-effect actions that 
were executed in s are consistent with the declarative 5 
semantics associated with S. In practical situations (e.g., in 
situations where the condition language includes integers 
with addition and multiplication) the determination of 
whether a snapshot is permissible or not is undecidable, i.e., 
there is no algorithm that always terminates that detennines iq 
whether, for a given DL schema S and snapshot s, whether 
s is permissible for S. Even when the condition language is 
restricted to permit atomic types with equality, deciding 
whether a snapshot is permissible is intractable. However, it 
is possible to develop sufficient conditions for permissible ^5 
that are tractable, even if the condition language is quite rich. 

In the algorithm developed here, execution of workflow S 
begins with a snapshot such that all source attributes are 
stable and all other attributes are in state UNINITIALIZED. 
Then a sequence of permissible snapshots is constructed, 20 
each one a strict extension of the previous one. Execution 
halts when a terminal snapshot is reached. 

A non-sotu-ce attribute A is absolute-enabled for permis- 
sible snapshot s if for each complete snapshot s' that extends 
s, A has state VALUE. A non-source attribute A is absolute- 25 
disabled for snapshot s if s is permissible and for each 
complete snapshot s' that extends s, Ahas state DISABLED. 

Given a permissible snapshot s over S then: 

A side-effect attribute A is absolute-eligible in s if A is 
absolute-enabled and each input attribute for A is 30 
stable, 

A non-side-effect attribute A is absolute -eligible in s if 
each input attribute for A is stable. 

A snapshot s-(a/i) over S is terminal if s is permissible 
and a(A)e {VALUE,DISABLED} for each Ae Tgt. That is, 35 
a snapshot is terminal if it is permissible and all target 
attributes are stable. 

A snapshot s over S is minimal terminal if s is terminal 
and s is not a strict extension of another terminal snapshot 
for S. 40 

An attribute A is absolute-tmneeded for permissible snap- 
shot s over S if for each minimal terminal snapshot s^o*^') 
thai extends s, &{A)^ {COMPUTED,VALUE}. 

As with the definition of permissible, the notions of 
absolute-ehgible and absolute-unneeded define, in an abso- 45 
lute sense, all eligible attributes and all unneeded attributes, 
for a given permissible snapshot during execution of a 
workflow schema. However, the actual computation of all 
eligible or unneeded attributes is not possible in practical 
situations, e.g., if the condition language includes integers 50 
with addition and multiphcation. Even if the condition 
language is limited to include only atomic types with 
equality, computing all eligible or unneeded attributes is 
intractable. Thus, a subset of absolute-ehgible and absolute- 
unneeded attributes is determined in order to improve the 55 
performance of a workflow execution. 

The basic and extended algorithms are used to determine 
which attributes to evaluate eagerly, that is, which attributes 
should be computed even though not aU of the attributes 
occurring in their associated enabUng conditions have 60 
become stable. Such an analysis involves partial computa- 
tions of conditions, since the conditions may depend on 
attributes which have not yet been computed. In order to 
represent such partial computations, a three valued logic is 
used. The truth value for a given condition may be true, 65 
false, or unknown. Instead of considering each enabhng 
condition as one indivisible three-valued logic formula, 
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enabhng conditions are represented by trees. This gives 
more precise knowledge as to which sub-formulas are true 
and which are false. Condition trees art used for this 
purpose. 

A condition tree of an enabling condition P is obtained 
from the parse tree (as well known in the art) of P by 
replacing each leaf node p of the form pred(li, . . . t^) with 
a tree T(p) defined as: 

the root node of T(p) is an AND operator node; 

pred(t,, ... tjt) is a leaf node of T(p); and 

VALUE (A) is a leaf node of TO) if A occurs in 
pred(t„ . . . t^). 
All the leaf nodes are direcdy connected to the root node. 

For example, consider the enabhng condition: (N0T(F=3 
AND G=4)) OR DISABLED (F). The condition tree for this 
enabhng condition is shown in FIG. 31. 

Now, in order to determine which tasks may be computed 
eagerly, a dependency graph is defined which will take into 
account the dependencies between the enabhng conditions 
and the attributes, and the dependencies between the 
attributes themselves. The dependency graph is defined as 
follows. Given a workflow schema S, the dependency graph 
of S, denoted D^, is a directed acyclic graph that is con- 
structed as follows: 

eadi enabhng condition in the workflow schema S is 
represented by its condition tree in D^. 

each attribute in A is a node in D^l ; 

there is an edge from the root node of each condition tree 
to the attribute node attached to the associated enabhng 
condition in S; 

there is an edge from an attribute A to a predicate node p 
if and only if A occurs in p; 

there is an edge from an attribute A to an attribute B if and 
only if A is an input attribute of B. 
As an example, consider the workflow schema represented 
by the data and enabling flow diagram of FIG. 32. As 
described above in conjunction with the data and enabhng 
flow diagram of FTG. 26, the data and enabling flow diagram 
of FIG. 32 illustrates the data flow dependencies (sofid hnes) 
and the enabling flow dependencies (broken lines) for a 
given workflow schema. Given the workflow schema rep- 
resented in FIG. 32, the dependency graph for that workflow 
schema is shown in FIG. 33. In FIG. 33, aU nodes belonging 
to an evaluation tree are condition nodes, with the remaining 
nodes being attribute nodes. The edges between attribute 
nodes are shown with broken lines and are data edges and 
the edges between condition nodes arc shown with sohd 
hnes and are called condition edges. 

Finally, prior to describing the basic algorithm, the notion 
of an extended snapshot must be defined. An extended 
snapshot is a tuple 

s=(a//,a, Hidden- att, Hidden- edge) where: 

(a) the state mapping a is a total function from Att into 
{UNINITIALIZED, ENABLED, READY, READY+ 
ENABLED, COMPUTED, VALUE, DISABLED) 

(b) The value mapping // is a partial function from Att into 
U{t(A)|A e Att}, such that for each A, /i(A) is defined 
iff a(A)=VALUE. If ^A) is defined then /<A)€ -c(A) 

(c) a maps each condition node to T (true), F (false), or U 
(unknown) 

(d) Hidden-att is the set of attributes which have been 
hidden (the notion of a hidden attribute will be 
described below); and 

(e) Hidden-edge is the set of edges (both data edges and 
condition edges) which have been hidden (the notion of 
a hidden edge will be described below). 
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Hie pseudo code for the basic algorithm for detennioing 
wbethcr a task is eligible or unnceded is shown in FIGS. 
34A-D. Generally, the algorithm starts at the beginning of 
the execution of a workflow instance and ends when the 
execution is completed. The prequalifier 2804 (FIG. 28) 
executes this algorithm for each workflow instance. The 
algorithm computes and incrementally maintains the states 
(in an array o[ ]) and the values (in the array ^ ]) of the 
attributes defined in the workflow schema 2810. In order to 
carry out its computations, the algorithm uses the depen- 
dency graph Dj. It incrementally computes a set of nodes 
called hidden-att such that the attribute nodes contained in 
the set hidden-att arc stable or unnceded, and a set of edges 
called hidden-edge where edges contained in hidden-edge 
arc edges which have been traversed by the algorithm, and 
do not have to be considered again by the algorithm. More 
generally, if an attribute or edge is "hidden", then the 
information embodied in that attribute or edge relevant to 
the algorithm has already been used during execution and 
possibly incorporated into the snapshot, and will not be 
needed in any subsequent step of the algorithm. The algo- 
rithm also maintains an array of three valued logic values 
(a[ ]) for condition nodes. The algorithm consists of two 
main phases. The first phase is an initiahzation phase which 
is executed once at the beginning of execution of a workflow 
instance. The second phase is the incremental phase which 
is executed each time a value of an attribute is computed by 
the execution engine 2812 and incorporated into the runtime 
workflow instances 2808. The incremental phase is also 
executed for the source attributes when the workflow 30 
instance is initially placed into workflow instances 2808. 

The pseudo-code for the basic algorithm shown in FIGS. 
34A-D will now be described. Section 3402 of the algorithm 
is the definition of the global variables. Section 3404 is the 
definition of some of the notations used in the algorithm. The 
initiahzation phase 3406 is executed once at the beginning 
of execution of a workflow instance in order to initialize the 
required data structures. In section 3408, the states and 
values of the attribute nodes of the dependency graph are 
initialized such that the state of the source attribute nodes are 
initialized to a slate of READY+ENABLED and all other 
attribute nodes are initialized to a state of UNINITIALIZED. 
The values Qz) of the attributes are set to nuU. In section 
3410, the logic values (a[ ]) for condition nodes are initial- 
ized to unknown. In section 3412, the set of hidden edges 
and hidden attributes is set to null. This is the end of the 
initialization phase 3406, 

The remainder of the pseudo code defines the incremental 
phase. Each time a new value for an attribute is computed by 
the execution engine 2812 (FIG. 28), the increment function 
3414 is called as part of the operation of the prequalifier 
2804. The increment function is also called by the prequali- 
fier 2804 at the beginning of processing a workflow instance, 
once for each source attribute. The increment function 3414 
then calls the propagate_att_change function 3422 which 
in turns recursively calls the propagate_cond_change func- 
tion 3450 in order to propagate changes along the depen- 
dency graph. Both the propagate_att change function 3422 

and the propagate_cond_change function 3450 caU the 
recursively defined functions hide_edge 3474 and hide_ 
node 3476. These functions will now be described in further 
detail. 

The increment function is shown in section 3414. As 
shown by the input section 3416, this function is called when 
a value v has been computed for an attribute A in the 
dependency graph G. First, the value (/i) of the attribute is 
updated in step 3418. Next, in section 3420 the propagate 
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att change function is caUed. If the current state of attribute 

A is READY, then the propagatc_att_change function is 
called with parameters indicating that the state of A should 
be updated to COMPUTED. If the current state of attribute 
A is ENABLED +READY then the propagatc_att__change 
function is called with parameters indicating that the state of 
A should be updated to VALUE. The increment function 
then ends. 

The propagate_att_change function is shown in section 
3422. The input to this function, as diown in section 3424, 
is an-attribute B and a state (0) for B. In section 3426 the 
state (a) for attribute B is updated. In section 3428, changes 
arc propagated up the dependency graph as a result of the 
newly computed attribute as follows. If the state of the 
attribute B has changed to VALUE or COMPUTED, then in 
section 3430 an attempt is made to evaluate predicate nodes 
which use the value of B. Thus, for each condition node in 
which B occurs in the predicate (line 3432) and for which 
the edge in the dependency graph from B to the predicate is 
not currently hidden (line 3434), the edge is hidden (line 
3436) and an attempt is made to evaluate the predicate using 
the new value of B. If the predicate can be evaluated, then 
the logic value (a) is updated to True or False and the change 
is propagated by caUing the propagate_cond_change func- 
tion (Une 3438). The propagate_cond_change function will 
be described in further detail below. Thereafter, for each 
attribute node C which has B as an input attribute, if B has 
the state VALUE and the value for B is the last input 
attribute needed for C to go stable, then attribute C is 
promoted to the READY state by caUing the propagate_ 
atl_change function (section 3440). 

If the state of attribute B is ENABLED, then in section 
3442 for each condition node p of the form VAL(B) the state 
of p (a[p]) is set to TRUE, and for each condition node p of 
the form DIS(B) the state of p (a[p]) is set to FALSE, and 
the changes are propagated by calling the propagate_cond_ 
change function. This processing takes place because when 
it is known that an attribute B is enabled, then the truth value 
of VAL(B) must be true, because the attribute will eventually 
be assigned some value. Similarly, the Uiith value of DIS(B) 
is known to be false. 

In a manner similar to that described above in conjunction 
with section 3442, if the state of attribute B is DISABLED, 
then in section 3444 for each condition node p of the form 
VAL(B) the state of p (ctfpD is set to FALSE, and for each 
condition node p of the form DIS(B) the state of p (o^pj is 
set to TRUE, and the changes are propagated by calling the 
prDpagate_cond__change function. Thereafter, in a manner 
similar to step 3440, for each attribute node C which has B 
as an input attribute, if the value for B is the last input 
attribute needed for C to go stable, then attribute C is 
promoted to the READY state by caUing the propagate_ 
att_change function (section 3446). 

The last line 3448 of the propagate_att__change function 
indicates that if the state of B has become DISABLED or 
VALUE (i.e., attribute B has become stable), then the node 
is hidden. 

The propagate_cood_change pseudo-code is shown in 
section 3450. This is a recursive algorithm which propagates 
condition changes up the dependency graph. The input to 
this function is a condition node p in the dependency graph 
G. The node n is the parent of the node p (line 3452). If the 
edge fi^om p-*n is not hidden, then section 3454 is executed. 
Otherwise, the function ends. First, the edge from p-»n is 
hidden (line 3456). If the parent of p (n) is an OR condition 
node section 3458 is executed. If the truth value of condition 
node p is true, then the truth value of the parent node n (ci[n]) 
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is set to true (because an OR condition is true if any of its 
components is true) and the change is further propagated up 
the dependeDcy graph by recursively calling the propagate_ 
cond_change function for node n (line 3460). If the truth 
value of condition node p is false and if there are no other 
Don-hidden edges into the parent n, then the truth value of 
the parent node n (a[n]) is set to false (because if there are 
DO more non-hidden edges then there are no more possibili- 
ties for a component of n to be true), and the change is 
further propagated up the dependency graph by recursively 
calling the propagate_cond_chang6 function for node n 
(3462). 

If the parent of p (n) is an AND condition node section 
3464 is executed. If the truth value of condition node p is 
false, then the truth value of the parent node n (cx[n]) is set 
to false (because an AND condition is false if any of its 
components is false) and the change is further propagated up 
the dependency graph by recursively calling the propagate_ 
cond_change function for node n (Hne 3466). If the truth 
value of condition node p is true and if there are no other 
non-hidden edges into the parent n, then the truth value of 
the parent node n (ci[n]) is set to true (because if there are 
no more non-hidden edges then there are no more possibili- 
ties for a component of n to be false), and the change is 
further propagated up the dependency graph by recursively 
caUing the propagate_cond_change function for node n 
(3468). 

If the parent of p (n) is a NOT condition node then the 
truth value of the parent node n (a[n]) is set to the inverse 
of the truth value of condition node p in 3470. 

If the parent of p (n) is an attribute node, then the enabling 
condition for node n can now be evaluated and section 3472 
of the pseudo code is executed. If the truth value of condition 
node p is true, then the propagate_att__change function is 
called to update the state of node n to ENABLED. 
Otherwise, if the truth value of condition node p is false, 
then the propagate_att_change function is called to update 
the state of node n to DISABLED. 

The hide edge function is shown in section 3474, The 

hide_edge function receives as input an edge (n,n') in g. The 
function will hide a node n if the received edge (n,n') is the 
last non-hidden edge emanating from n. 

The hide_node function is shown in seaion 3476. The 
hide_node function receives as input a node n in g. The 
function hides all edges into n. 

When the basic algorithm is finished executing, there is a 
new updated snapshot stored in the memory of the system. 
Because of properties of the algorithm, this snapshot is 
permissible. A determination as to which attributes are 
eligible is made as follows. A non-side ejQfect attribute is 
eUgible if its state (a) is READY or READY+ENABLED. 
Aside effect attribute is eUgible if its state (a) is READY+ 
ENABLED. Recall that if an attribute A is determined to be 
eligible for execution then the task corresponding to execu- 
tion of the module that defines A is also viewed as eligible 
for execution. Thus, since side-effect tasks have significant 
impact external to the workflow system, a side-effect task is 
eligible for eager evaluation only if the data is available for 
its evaluation and if it is known that its enabling condition 
will ultimately be true (i.e. the corresponding attribute is in 
sUte READY+ENABLED). No n -side-effect tasks, on the 
other hand, have no significant external impact, and a 
non-side-effect task may be considered as eligible for eager 
evaluation when its data inputs are available, whether or not 
it is known that its enabling condition will ultimately be true 
(i.e. the corresponding attribute is in state READY or 
READY+ENABLED). 
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Further, a determination as to which attributes, and hence 
which tasks, arc xmncedcd is made as follows. An attribute 
A is unnccdcd if the node for A in the dependency graph is 
hidden and the state of A is not COMPUTED or VALUE. 
The node of an attribute may become hidden if its value will 
not be used, directly or indirectly, in the evaluation of any 
target attribute. As a particular example, if the attribute is an 
input for some target attribute but partial evaluation of the 
cnabhng condition for the target attribute indicates that the 
enabling condition will take the value FALSE, and the 
attribute will not be used, directly or indirectly in the 
evaluation of any other target attribute, then the node of the 
attribute will become hidden. Recall that if attribute A is 
unneeded then the task corresponding to execution of the 
module producing A is also viewed as unneeded. 

At this point, the prequahfier 2804 (FIG. 28) identifies all 
tasks which are eligible and not unneeded as candidate tasks 
and provides these candidate tasks to the candidate task pool 
2802. If a task which was previously identified as ehgible is 
newly identified as unneeded, then the corresponding task is 
removed from the candidate task pool 2802. 

In determining that an attribute is ENABLED, READY+ 
ENABLED, or DISABLED the algorithm may use a partial 
evaluation of the enabling condition of the attribute, i.e., an 
evaluation of all or part of the ultimate value of the enabling 
condition based on the states and/or values of some but not 
all of the attributes occurring in the enabling condition. 

It is noted that the miming time of this algorithm for 
executing the workflow S on an input is linear in the number 
of edges in D,. 

Given the above description and the pseudo code in FIGS. 
34A-34D, one skilled in the art could readily implement the 
algorithm. 

The basic algorithm will therefore update the snapshot 
when a new attribute value is computed and the updated 
snapshot allows a determination to be made as to whether a 
task is eligible and/or unneeded. As described above, 
another characteristic of tasks, namely necessary, is also 
used in order to improve the performance of the decision 
engine 104. If a task is known to be necessary to complete 
the workflow execution, then that task should be given high 
priority for evaluation. 

Pseudo code for the extended algorithm for determining 
whether a task is necessary is described below in conjunc- 
tion with FIGS, 35A-35G. In order to describe the extended 
algorithm, several definitions must be introduced. 

Given an extended snapshot s-(aj//,a, Hidden-att, 
Hidden-edge) , an attribute A is a relative source attribute if 
each in-edge of A is an element of Hidden-edge. 

A snapshot s-(aj/^,a, Hidden-att, Hidden-edge) is eager if 
and only if: 

(a) For each relative source attribute A in S, o(A) 
e{VALUE, DISABLED, READY+ENABLED}; 

(b) For each non-relative source attribute A, cr(A) 
^ENABLED iff a(n)=T where n is the root node of the 
enabling condition of A; 

(c) For each non-relative source attribute A, a(A) 
^DISABLED iff a(n)=F where n is the root node of the 
enabling condition of A; 

(d) For each non-relative source attribute A, cr(A) 
^ READY iff for each input attribute B of A, a(B) 
€{VALUE, DISABLED}; 

(c) For each non-relative source attribute A, a(A) 
e{COMPUTED,VALUE} iff MA) is defined; 

(f) for each condition node n, a(o) is defined accordance 
with the basic algorithm (section 3450) based on the 
value of a and ^; 
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(g) Hidden-node is defined in accordance with the basic Given the above properties and definition of necessary, it 
algorithm (section 3474) based on the value of o and /x; is noted that the notion of necessary is defined in an absolute 

(h) Hidden-edge is defined in accordance with the basic sense, and inchides all attributes whose values wiU be 
algorithm (section 3476) based on the value of a and//, necessary for constructing a terminal snapshot using the 

It is noted that the snapshots produced by the basic algorithm ^ basic algorithm (or more generally, execution based on the 

will satisfy the above criteria for an eager snapshot. construction of a sequence of eager snapshots, each one 

There are four properties that are useful in determining extending the preceding one). However, the actual compu- 

necessary tasks: True-Necessary, False-Necessary, Value- ^^^^ °^ ^11 necessary attributes is not possible in practical 

Necessary, and Stable-Necessary. True-Necessary and situations, e.g., if the condition language includes integers 

False-Necessary properties give information about the nee- lO with addition and multiplication. Even if the condition 

essary relationship between an attribute and a predicate. language is limited to include only atomic types with 

Intuitively, an Attribute A is True-Necessary for a condition equaUty, computing all necessary attributes is intractable.' 

node p if in order for a(p)-T (in later snapshots), the value Thus, a subset of necessary attributes is determined in order 

of A must be known. More formally: to improve the performance of a workflow execution. 

Let D be a dependency graph, and let s«(a//,a. Hidden- ^'^^'^^^^ algorithm for finding necessary altiibutes 

att, Hidden-edge), be an eager snapshot An attribute A certam propagation rules m order o determme whether 

is True-Necessary for a condition node p, if the fol- true-necessary, false -ne«:ssary, stable- 

lowine is true* necessary or value-necessary. Generally, the framework for 

if for each eager snapshot M&j/, a\ Hidden-atf, oxtended algorithm is as foUows. Given a dependency 

Hidden edec^ r v ^ 20 graph which is mamtained as described above m connection 

such that s<s-, and a'(p)=X then &(A) is in {VALUE, 'hf ^'^^ ^^''^ ^T^jT^ 

COMPUTED V \ y I associated with them, and certam attributes may be hidden. 

Intuitively, an Attribute A is False-Necessary for a con- ^n^/nv "'^pp'"! nv rM AntL'n "Tk '° ' 

dition node p if in order for a(p)=F (in later snapshots), the °[ ^.^^.tl^^^P' '^^ "^^"""""r 7^' 

value of A must be known, ivfore formally: ^ ^^eUier the attnbuU b true-Decessary, false- 

_ . , , , , ^ \ „. . , necessary, stable-necessary or value-necessary for some 

Ut D be a dependency graph, and let s-(a//,a, Hidden- ^^^^ y^- propagation rules described below, these 

att. Hidden-edge), be an eager snapshot. An attribute A erties may be propagated up the dependency graph. If 

IS False-Necessary for a condition node p, if the fol- ^^^^^^^ ^ ^^^^^ ^^-^^ stable-necessary for a target 
lowing is true: .30 attribute, then that attribute is considered necessary for 

if for each eager snapshot s'=(a'^ ,a , Hidden-atf ^ i^tion of the workflow TTiese propagation rules will 

Hidden-edge') such that s<s', and a'(p)=F, then o(A) described. 

is in {VALUE, COMPUTED}, p-^j^ ^ definition is necessary. A node n is a relative- 
Value-Necessary and Stable-Necessary properties give predecessor of a node m in snapshot s if the edge (n,m) is an 
mformation about the necessary relaUonsbip between two 35 dependency graph G and (n,m) t Hidden-edges, 
attnbutes. Intuitively, an attabute A is Value-Nece^ary for ^.^^^ definition, three sets of propagation conditions 
an attnbute B if the value of A must be l^own later ^^^^ ^^^^ ^^^^^^ conditions to 
snapshots m which the state of B is COMPUTED or p^^p^gate Fake-necessary and True-necessary properties 
VALUE. More formally: ^^^^^^ condition nodes. The second set gives sufBcient 
Let D be a dependency graph, and let s=(a^,a, Hidden- 40 conditions for a node A to be stable-necessary. The last set 
att, Hiddea-cdge), be an eager snapshot. An attribute A gives a sufiBcient condition for a node A to be Value- 
is Value-Necessary for an attribute node B, if the necessary. 

following is true: The sufficient propagation conditions for True-necessary 

if for any eager snapshot s'«h(a'/<',a', Hidden-atf, and False-necessary are as follows. 

Hidden-edge') such that s<s*, and a'(B) is in 45 Let s be an eager snapshot, A an attribute node, and p a 

{VALUE, COMPUTED}, then & (A) is in {VALUE, non-hidden predicate node: 

COMPUTED}. ^gjj p is an OR node, then A is true-necessary for p, 

Intuitively, an attribute A is Stable -Necessary for an if A is true-necessary for all the relative predecessors of 

attribute B if the value of A must be known for later p 

snapshots in which the state of B is VALUE or DISABLED en /^\ nn. r^n a 4U a • n 1^^ kt^ * 

^„ . , , . ^, ^ 1, (2) When p IS an OR node, then A is False-Necessary for 

(i.e. B is stable). More formally: c a ■ r t c *i* j * j 

^ ^ ' p, if A is false-necessary for at least one direct prede- 

Let D be a dependency graph, and let s=(a/i,a. Hidden- cessor of p 

att. Hidden-edge), be an eager snapshot. An attribute A p js an AND node, then Ais true-necessary for 

IS Stable-Necessary for an attnbute node B. if and only .^^^ true-necessary for at least one relative prede- 

if for any eager snapshot s'=(a>',a', Hidden-att', SS ca^sot of p 

Hidden-edge") such that s<s', and a'(B) is in {VALUE, i.s-ar^ • antt. j .u a • f 1 c 

DISABLED}, then a'(A) is in {VALUE, COM- (4) When an AND node then A is false-necessary for 

PUTED} p, if A IS False-necessary for all relative predecessors of 

Thus, there are two ways for an attribute A to be Stable- P* 

Necessary for attribute B: 1) Ais Value-Necessary for B (this 60 (5)When p is a NOT node, then A is true-necessary for p, 

implies that A is enabled) and A is False-Necessary for the if A is false-necessary for the relative predecessor of p. 

Root of the enabling condition of B; or 2) A is True- (6) When p is a NOT node, then A is False-necessary for 

Necessary for the root of the enabling condition ofBandA p, ifAis true-necessary for the relative predecessor of 

is False-Necessary for the root of the enabling condition of p- 

B. 65 (7) When p is a VAL(B) predicate, then A is true- 

Ihus, given these properties, an attribute Ais necessary if necessary for p, if A is True- necessary for the root node 

A is Stable- Necessary for some target attribute. of the enabling condition attached to B. 
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(8) When p is a VAL(B) predicate, then A is false- 
necessary for p, if A is faJsc -necessary for the root node 
of the enabling condition attached to B, 

(9) When p is a DIS(B) predicate, then A is true-necessary 
for p, if A is false-necessary for the root node of the 
enabling condition attached to B. 

(10) When p is a DIS(B) predicate, then A is false- 
necessary for p, if A is true-necessary for the root node 
of the enabling condition attached to B. 

(11) When p is a predicate of the form pred(ti, . . . ,t,), 
then A is true-necessary for p, if it is value-necessary 
for at least one relative predecessor of p. 

(12) When p is a predicate of the form pred(ti, . . . ,tJ^), 
then A is false-necessary for p, if it is value-necessary 
for at least one relative predecessor of p. 

The sufficient propagation conditions for stable-necessary 
are as follows. Let s be an eager snapshot, and let A and B 
be attribute nodes where A and B are not hidden: 

(13) A is Stable-necessary for B, if a(A)^ENABLED and 
B is enabled in s and A is Value-necessary for B. 

(14) A is stable necessary for B if o(A) ^ENABLED and 
B is not enabled in s and A is value-necessary for B and 
A is false necessary for the root of the enabling con- 
dition of B. 

(15) Ais stable necessary for B if o(A) ^ENABLED and 
B is not enabled in s and Ais true-necessary for the root 
for the enabling condition of B and A is false-necessary 
for the root of the enabling condition of B. 

The sufficient propagation conditions for value-necessary 
are as follows. Let s be an eager snapshot, and let A and B 
be attribute nodes where A and B are not hidden: 

(16) Ais value-necessary for B if a(A) ^ENABLED and 
A is an input attribute of B. 

(17) Ais value -necessary for B if n(A) ^ENABLED and 
A is stable-necessary for at least one of the input 
attributes of B. 

(18) A is value -necessary for A if A e {ENABLED, 
READY+ENABLED}. 

Finally, the propagation mle for an attribute to be neces- 
sary is as follows: 

(19) An attribute Ais necessary if it is stable -necessary for 
a target attribute. 

The pseudo code for the extended algorithm for comput- 
ing whether an attribute is necessary is shown in FIGS. 
35A-35G. This extended algorithm is an extension of the 
basic algorithm described above in conjunction with FIGS. 
34A-34D. Thus, the extended algorithm could be consid- 
ered the main algorithm, which in turn calls portions of the 
basic algorithm. The extended algorithm starts at the begin- 
ning of the execution of a workflow instance and ends when 
the execution is complete. At each step of the execution, it 
computes the necessary attributes and marks them by setting 
a corresponding element in an array to true. This algorithm 
is based on the 19 propagation rules described above. The 
basic approach of the algorithm is, for each attribute A, to 
propagate along the dependency graph the properties true- 
necessary, false -necessary, value-necessary, and stable nec- 
essary. When the property stable-necessary for an attribute 
node A reaches a target attribute node, this means that 
attribute A is necessary. 

The extended algorithm takes advantage of the stability 
(i.e. once discovered, a necessary property cannot change) of 
the necessary properties to avoid re -computing necessary 
properties discovered in prior steps of the execution. The 
algorithm is incremental in the sense that it propagates the 
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necessary properties along the dependency graph G by only 
computing new necessary properties at each step. The nec- 
essary properties are kept trade of by four global variables, 
F-N[ I I T_>J[ I ], V_J4 I 1 and S_N[ ][ ], each of 

5 which are integer matrices. T_J^ ][ ] associates an integer 
value to each pair (p,A) where p is a condition node in G and 
A is an attribute node in G. T_N[p][A]=0 indicates that the 
attribute A is true- necessary for the condition node p. F_N[ 
][ ] associates an integer value to each pair (p A) where p is 

10 a condition node in G and A is an attribute node in G. 
F_N[p][A]=0 indicates that the attribute A is false- 
necessary for the condition node p. V__N[ ][ ] associates an 
integer value to each pair (B,A) where B and A are attribute 
nodes in G. V_N[BIA]=0 indicates that the attribute A is 

15 value -necessary for the attribute node B. S_N[ ] associates 
an integer value to each pair (BA) where B and A are 
attribute nodes in G. V_JSI[BIA]=0 indicates that the 
attribute A is stable-necessary for the attribute node B. 
At the beginning of the execution, each clement of these 

20 matrices is initialized by a positive integer value. The initial 
value indicates how many decrements are required by the 
algorithm to guarantee that the corresponding necessary 
property is true (i.e. value=0). During execution, the algo- 
rithm decrements the value according to the propagation 

25 rules. For example, if p is an OR node, T__N[p][A] is 
initiahzed by the number of incoming edges to p. This 
corresponds to rule number (1) which states that A is 
true- necessary if all its predecessors are true necessary. 
F _N[p][A] is initialized with 1 since rule (2) stales that Ais 

30 false necessary as soon as one of its predecessors is false - 
necessary. 

The extended algorithm will now be described in con- 
jtmction with FIGS. 35A-G. The global variables are 
defined in section 3502. The variables defined in section 

35 3504 are the same as those defined in section 3402 (FIG. 34) 
with respect to the basic algorithm. The remaining global 
variables in section 3502 have been described above. The 
initialization phase of the algorithm is shown in section 
3506. This section initializes the variables. Section 3508 is 

40 a call to the initialization phase of the basic algorithm, which 
was described above in conjunction with section 3406 of 
FIG. 34. Section 3510 initializes the variables T_N[ ][ ] and 
F_N[ ][ ] as described above in accordance with the 
propagation rules. In section 3511, for each OR condition 

45 node p, the corresponding entries T_N|j)IA] are initialized 
to the number of predecessors of the node, in accordance 
with propagation rule (1). This is because for an attribute A 
to be true-necessary for p, A must be true necessary for all 
relative predecessors of p. In this way, T_N[p] [A] will not 

50 reach 0 (indicating that attribute A is true necessary for 
condition node p), xmtil it is decremented for each relative 
predecessor of p. Also, for each OR condition node p, the 
corresponding entries F_Jvr[p][A] are initialized to 1, in 
accordance with propagation rule (2). This is because for an 

55 attribute A to be false-necessary for p, A must be false 
necessary for at least one relative predecessor of p. In this 
way, F_N[p] [A] will reach 0 (indicating that attribute Ais 
false necessary for condition node p), when it is decre- 
mented for any one relative predecessor of p. 

60 The remainder of section 3510 continues in a similar 
manner inidaliziDg T_N and F_N for AND nodes, NOT 
nodes, nodes of the form VAL(A), DIS(A), and pred (t^ , . . . , 
ij^ in accordance with the corresponding propagation rules. 
The corresponding propagation rules are indicated in section 

65 3510 of FIG. 35B. Further, in section 3512 all attributes are 
initialized to not stable -necessary and not value-necessary 
by setting S_N[ I ] to 1 and V_J^ ] [ ] to 1 respectively. 
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la section 3513 all attributes are initialized to not Qeccssary 
by setting N[ ] to false. 

TTie remaining portion of the extended algorithm is the 
incremental phase of the algorithm. This phase is called at 
each step of the workflow execution when a new attribute 5 
value is obtained as part of the operation of the pre qualifier 
2804. It updates the T_N, F_N, V_N, S_N, and N data 
structures according to the new eager snapshot computed by 
the basic algorithm. The incremental phase contains three 
steps. The first step is the preparation step. This step records 10 
information about the difference between the previous eager 
snapshot and the new eager snapshot computed by the basic 
algorithm: The second step is the instigation step which 
computes new necessary properties which immediately fol- 
low from the new information in the snapshot. The third step 15 
is the propagation step which propagates the new necessary 
properties computed in the instigation step. 

The variables for the increment phase are defined in 
section 3516. Section 3518 defines the variables that are 
used to store the status of the current snapshot. These 20 
variables are described in further detail in the figure. Section 
3520 defines variables that store attributes which are newly 
ENABLED or newly READY+ENABLED and edges which 
are newly hidden. Section 3522 defines variables whidi are 
used to store attributes which have become newly value- 25 
necessary (new_V_N), newly stable-necessary (new_S_ 
N), newly true-necessary (new_T_N), or newly false - 
necessary (new_F_N), as a result of the instigation step. 

The preparation step is shown in section 3524. This step 
sets the values of prev__hidden_edges and prev_E and then 30 
calls the increment procedure of the basic algorithm in step 
3526. The increment procedure is described above in con- 
junction with section 3414 of FIG. 34B. After execution of 
the increment procedure, there is a new snapshot which is 
now operated upon by the remainder of the extended algo- 35 
rithm. 

The instigation step is shown in section 3528. This step is 
divided into 4 cases. Case 1 is shown in section 3530. This 
case implements propagation rule (18) which indicates that 
an attribute A is value-necessary for itself if it is in the state 40 
ENABLED or ENABLED+READ Y This section 3530 thus 
determines which attributes A have newly entered the set of 
states {ENABLED, ENABLED+READY} and for those 
attributes, sets V_N[A][A]=0, thus indicating that the 
attribute is value-necessary for itself. The pair (A^) is also 45 
added to the set of pairs of attributes which are newly 
value-necessary (new_V_N). Case 2, shown in section 
3532 implements propagation rule (13) which indicates that 
an attribute A is stable-necessary for an attribute B if the 
state of A is greater than or equal to ENABLED (i.e. 50 
ENABLED or ENABLED+READY), B is enabled, and A is 
value-necessary for B. This section 3532 applies this propa- 
gation rule for each newly enabled attribute B (i.e., those 
attributes in the set A_E) and updates new_S_N as appro- 
priate. 55 

As shown in section 3534, the variable A_HIDDEN_ 
EDGE is used to hold edges that have been newly hidden 
during this iteration of the algorithm. Variables prev_T_N, 

prev_F_N, new T _N and new F N are used to keep track 

of node-attribute pairs that become true-necessary or false- 60 
necessary during this execution of the algorithm. 

Case 3, shown in section 3536 implements propagation 
rule (1) and operates as follows. If an edge (n,p) is hidden, 
then the predicate node n was computed to be false, in which 
case it is no longer relevant whether attribute A is true- 65 
necessary for n. Thus, if attribute A is not already true- 
necessary for n (i.e. T__N[p][A]?iO) then the value of T_J^ 
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[p][A] is decremented, which reduces the number of relative 
predecessors for which A needs to be true-necessary. Case 4, 
shown in section 3538 implements propagation rule (4) and 
operates as follows. If an edge (n,p) is hidden, then the 
predicate node n was computed to be false, in which case it 
is no longer relevant whether attribute A is false-necessary 
for n. Thus, if attribute A is not already false-necessary for 
n (i.e. F_N[plA]^0) then the value of F_N[plA] is 
decremented, which reduces the number of relative prede- 
cessors for which A needs to be false-necessary. 

The propagation step 3540 caUs the new_^rop agate 
routine, which is shown in section 3542. The new_ 
propagate routine receives, and operates on, the set of 
attributes which have been found to be newly value- 
necessary (new_V__N), stable-necessary (dcw_Si3 N), 
true-necessary (new_T_N), or false -necessary (new_P__ 
N) as a residt of the instigate step. Section 3544 calls the 
appropriate propagation routine for the newly necessary 
attributes. Also, for attributes which arc newly value- 
necessary, propagation rule 16 is implemented in section 
3546. 

The newly value-necessary attributes are propagated in 
the propagate_V_N routine 3548. Section 3550 imple- 
ments propagation rule (13). If the condition is satisfied, 
then A is set to stable -necessary for B (i.e. S_N[B][A] is set 
to 0), and this new necessary property is farther propagated 
by calling the propagate_S routine. Propagation rule 
(14) is implemented in section 3552 and if an attribute is 
found to be stable -necessary as a result, that property is 
further propagated by calling the propagate_S_N routine. 
Propagation mle (11) is implemented in section 3554 and if 
an attribute is found to be true-necessary as a result, that 
property is further propagated by calling the propagate_ 
T_N routine. Propagation rule (12) is implemented in 
section 3556 and if an attribute is found to be false-necessary 
as a result, that property is further propagated by calling the 
propagate_F _JS routine 

The newly stable-necessary attributes are propagated in 
the propagate_S _J>1 routine 3558. Propagation rule (17) is 
implemented in section 3560 and if an attribute is found to 
be value -necessary as a result, that property is further 
propagated by calling the propagate_V_N routine. Propa- 
gation rule (19), which deteraaines whether an attribute is 
necessary for the workflow execution, is implemented in 
step 3562 

The newly false-necessary attributes are propagated in the 
propagate_F_N routine 3564 and the newly true-necessary 
attributes are propagated in the propagate_T _N routine 
3566. The rules implemented by various portions of these 
routines are indicated in FIG. 35. These routines would be 
well understood by one skilled in the art given the above 
description of the other propagation routines. 

It is to be understood that the extended algorithm is only 
one implementation of the propagation rules described 
above. One skilled in the art could readily implement these 
propagation rules using other algorithms. Further, one 
skilled in the art could also use and implement other or 
additional propagation rules. 

It is noted that the running time of the extended algorithm 
when executing workflow schemas S on one input is 
0(|N||E[) where N is the set of nodes in D^ and E is the set 
of edges in D^. 

A task may be identified as necessary because the value 
produced by the task is value-necessary for some target 
attribute, i.e., the value produced by the task is used, cither 
directly or indirectly, in the evaluation of the target attribute. 
A task may be identified as necessary because the value 
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produced by the task is true-necessary and false-Dccessary 
for a target attribute, i.e., the value produced by the task is 
necessary, either directly or indirectly, to determine that the 
enabling condition for the target attribute is true and that it 
is necessary, either directly or indirectly, to detenaaine that 
the enabling condition for the target attribute is false. 

Given the above description and the pseudo code in FIGS. 
35A-35G, one skilled in the art could readily implement the 
algorithm. 

Thus, the algorithms shown in FIGS. 34 and 35 compute 
the three key properties of eligible, unneedcd, and necessary. 
Referrmg now to FIG. 28, the algorithms of FIGS. 34 and 35 
arc executed by the prequalifier 2804 and thus the three 
properties arc computed by the prequalifier 2804. Tasks 
which are eligible may be provided to the candidate task 
pool 2802 for eager evaluation. However, if an eligible task 
is determined to be imnecded, then it is either not provide to, 
or removed from, the candidate task pool 2802. Further, if an 
eligible task is determined to be necessary, then it is marked 
as high priority in the candidate task pool 2802 so that it may 
be scheduled by the task scheduler 2806 for high priority 
execution by the execution engine 2812. This improves the 
performance of the overall operation of the decision engine 
104. The prequalifier 2804 updates the candidate task pool 
2802 after all source attributes have been processed, and also 
after a new attribute value has been computed. In this 
manner, tasks which are known to be necessary for the 
completion of the workflow (eUgjble and necessary tasks) 
will be performed before tasks which are merely eligible. 
This is desirable because tasks which are merely eligible 
may actually be unneeded, and thus such tasks should not be 
given high priority. 

It is not required that the enabling conditions of modules 
involve or refer to events, such as the initiation or comple- 
tion of tasks, i.e., the executions of modules. In the context 
of DL specifications, conditions may test only the stable 
states and values of attributes and modules. Thus, there is an 
implicit dependence between the truth value of an enabling 
condition and the times at which the modules and attributes 
referred to in the condition become stable. However, once 
these modules and attributes become stable they cannot 
change value, and so the truth value of the condition will 
remain the same for the duration of the execution of the 
workflow instance. This is a result of the acyclicity condition 
imposed on DL specifications and the fact that each attribute 
is produced by only one module. Thus, once the truth value 
of an enabling condition is established, the particular times 
at which that truth value is tested by an execution algorithm 
will not affect the overall outcome of the workflow instance. 
Id particular, unless the enabling conditions explicitly refer 
to the timing of module execution, the duration of process- 
ing of tasks will not affect the truth value of an enabUng 
condition, and, in the absence of optimizations as described 
above, will not affect whether or not a given module is 
executed during a workflow instance. 

The independence of module execution in workflows 
based on DL specifications stands in marked contrast with 
workflow systems that use enabfing conditions that are 
required to explicitly refer to events such as the initiation or 
completion of tasks. Enabling conditions in such systems 
have the form "on <event> if <condition>". The intended 
semantics is that during execution the <condition>should be 
tested immediately after the <event> occurs. In these 
systems, the truth value of <condition> may be defined and 
change value over time. Thus, the outcome of testing the 
enabling condition, i.e., the decision of whether the corre- 
sponding module is executed or not, may depend on the 
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exact time that the <event> in the enabling condition occurs. 
In particular, the enabling conditions and the decisions they 
embody may depend on the durations of execution of 
different modules. This dependence implies that analysis of 
5 the behavior of such systems is at roughly the same level of 
difficulty as the analysis of the behavior of procedural 
programs. 

As dcscaibed above, decision modules are evaluated using 
computation rules and a combining poHcy. In addition, a 

10 novel graphical user interface (GUI) is used to display a 
representation of the evaluation of decision modules. The 
GUI is particularly advantageous for imderstanding and 
debugging the semantics of the workflow system, and for 
understanding how different execution strategics affect the 

15 processing of different kinds of inputs. 

In describing the GUI, we again make the simplifying 
assumptions made above that we arc given a declarative 
module in which each internal module produces exactly one 
output attribute and may have a side-effect. Further, once 

20 enabled, it is assumed that all internal modules will always 
produce a value and will never produce an exception value. 
For this discussion, the term non-decision module refers to 
internal modules that are not decision modules. The term 
non-decision attribute refers to an attribute whose defining 

25 module is a non-decision module. 

The GUI may be implemented in connection with essen- 
tially any policy for evaluating decision attributes, i.e., those 
attributes that are evaluated as speciBed by a decision 
module. In order to iUustrate the GUI most clearly, we do not 

30 use the policy for evaluating decision attributes described 
above. Instead, the GUI is described using an execution 
policy that is eager with respect to the evaluation of com- 
putation rule conditions and computation rule terms. The 
contribution rule terms are also referred to as "contribu- 

35 tions" because, as described above, these terms contribute 
values to an attribute if the condition is true. Given the 
description herein, one skiUed in the art could readily 
implement the GUI in connection with other execution 
policies. 

40 In order to describe the eager execution policy for deci- 
sion attributes, we modify the notion of snapshot used 
earlier, in two ways. The first modification is to restrict the 
set of slates that decision modules can be in, and the second 
modification is to permit computation rule conditions and 

45 contributions to be evaluated in an eager fashion. 

Recall in the previous discussion that non-side effect 
modules can have states as shown in FIG. 29. In the current 
discussion we use a refinement of the state diagram shown 
there for decision modules. Specifically, we use the FSA of 

50 FIG. 36 for decision modules. Each decision module starts 
in the state READY, even if the source attributes for the 
decision module are not yet stable. The conditions and/or 
contributions of rules in a decision module may be evaluated 
eageriy, as the attributes used by those conditions and/or 

55 contributions become stable. If all the rule conditions are 
evaluated, and the contributions of all rules with true con- 
dition are evaluated, then the value for the attribute can be 
determined, and the module is moved into state COM- 
PUTED. Alternatively, if the enabling condition of the 

60 decision module is determined to be true, the module may 
move to state READY+ENABLED. The states VALUE and 
DISABLED are the same as described above in connection 
with FIG. 29. 

FIG. 37 shows the FSA used for each computation rule. 
65 Each rule begins in state READY. If a sufficient number of 
attributes in the rule condition become stable for a determi- 
nation to be made that the rule condition is, or will even- 
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tually become, TRUE, then the rule moves to state 
CONDmON_TRUE. Alternatively, if a siifiBcient number 
of attributes in the rule contributioD become stable such that 
the eventual value of the contribution can be computed, then 
the rule moves lo state C0NTRIBUnON_C0MPUTED. 5 
Thereafter, if both the rule condition is determined to be true 
and the contributed value is computed, then the rule moves 
to state CONTRIBUTED_VALUE. Alternatively, if a suf- 
ficient number of attributes in the rule condition become 
stable for a detercnination to be made that the rule condition lO 
is, or will eventually become, FALSE, then the rule moves 
to state CONDmON_FALSE. 

Further in connection with the description of the GUI, the 
notions of workflow schema and snapshot presented above 
arc modified. First, assume that a workflow schema has the 15 
form S=(Alt, Src, Tgt, Eff, Cnd, Mod, Dec), where 

1. Components Att, Src, Tgt, Efif Cnd, and Mod are as 
described above; and 

2. Dec is a set of pairs {(Rules^ CP^| A is a decision 
attribute}, where for each decision attribute A, Rules^ ^ 
is the set of computation rules in the module outputting 
A, and CP^ is the combining pohcy for the module 
outputting A. 

For schema S, we use Rules to denote the set U{Rules^|A 
is a decision attribute in S}, i.e., the set of all computation ^ 
rules occurring in the decision modules of S. 
Second a snapshot for S is defined to be a pair s-(a:^) where 

1. the state mapping a is a total function from AttU Rules 
such that a maps 

a. each decision module to {READY, ENABLED+ 
READY, COMPUTED, VALUE, DISABLED}, 

b. each non-decision, non-side-effect module to 
{UNINITIALIZED, ENABLED, READY, 
ENABLED+READY, COMPUTED, VALUE, 
DISABLED}, 

c. each non-decision, side-effect module to 
{UNINITIALIZED, ENABLED, READY, 
ENABLED+READY, VALUE, DISABLED}, and 

d. each computation rule to {READY, CONDITION_ 
TRUE, CONTRIBUTION_COMPUTED, 
CONTRIBUTED_VALUE, CONDITION^ 
FALSE}. 

2. The value mapping is a partial function firom 
AttURules such that maps 

a. Att into U{T(A)|AeAtt}, such that for each A, if /<A) 
is defined then //(A)eT3(A), and such that for each A, 
fi(A) is defined iff a(A)oVALUE or a(A)» 
COMPUTED. 

b. each rule r in Rules to a value with the type of the 
contribution of r, such that /^(r) is defined iff ci(r)a 
CONTRIBUTION_COMPUTED or a(r) = 
CONTRIBUTED_VALUE. 

One snapshot s' extends another snapshot s (specified as 
s<s') if for each attribute A: 

(a) if A has a value in s, then A has the same value in s'; 
and 

(b) the state of A in s'^ the state of A in s, where ^ js 
relative to the FSAs of FIGS. 29, 30 and 36 

and for each computation rule r: 

(c) if r has a contributed value in s, then r has the same 
value in s'; and 

(d) the state of r in s'^ the state of r in s, where ^ is 
relative to the FSA of FIG. 37. 

Snapshot s' strictly extends snapshot s if s<s' and s*is'. A 65 
snapshot is complete if each attribute is stable and each 
computation rule is in state CONTRIBUTED_VALUE or 
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CONDmON_FALSE- A snapshot is terminal if each target 
attribute is stable. 

For the purposes of describing the GUI, it is not necessary 
to use a specific algorithm or policy for executing a declara- 
tive workflow. We assume here that execution of workflow 
S begins with a snapshot such that all source attributes are 
stable, all internal modules are in state UNINITIALIZED (or 
READY, for decision modules), and all computation rules 
are in state READY. Then a sequence of snapshots is 
constructed, each one a strict extension of the previous one. 
Execution halts when a terminal snapshot is reached. 

The GUI will now be described in connection with the 
declarative module INFO_ABOUT_CUSTOMER as 
shown in FIG. 5. This module has two source attributes, 
CUST_JIEC and ACCOUNT_NUMBER. There are eight 
internal modules 504, 508, 512, 516, 520, 524, 528, and 532. 
Modules 504, 508, and 512 arc non-decision modules. 
Modules 516, 520, 524, 528, and 532 are decision modules. 
The specification of the INFO^^BOUT- CUSTOMER mod- 
ule and its internal modules has been described in detail 
above. Reference to that description may be helpful during 
the following description of the GUI. 

FIGS. 38 and 39 are illustrative display screen shots and 
are used to illustrate the GUI. The figures show information 
about two snapshots that might arise during a hypothetical 
execution of the INFO_ABOUT__CUSTOMER module. 
FIG. 38 shows execution information near the beginning of 
execution and FIG. 39 shows execution information some- 
where in the middle of execution. 

Referring to FIG. 38, the display is in a grid fomaat, with 
the rows labeled with numbers and the columns labeled with 
letters. The intersection of a row and a column defines a ceU. 
Each column of the display corresponds to an attribute of the 
INFO_AB0UT_CUSTOMER module. The finst two rows 
provide information about how the attributes are computed. 
Row 1 indicates the name of the module computing the 
attribute. For ease of cross-reference, row 1 of FIG. 38 
includes the corresponding caU-out identification of the 
module from FIG. 5, Such call-out numbers would not be 
mcluded in an actual embodiment of the GUI. Row 2 
indicates the manner of computation. For non-decision 
modules, row 2 indicates the type of the module (e.g., 
"foreign"). For decision modules, row 2 displays a short 
description of the combining policy of the module. This 
short description could be specified, for example, in the 
textual description of the combining policy. As an 
altemative, row 2 could display the name of the function 
specifying the combining pohcy for the module. The 
attribute names are shown in row 3. 

Rows 4 and 5 display the evaluation status of attributes. 
The fourth row displays the value of an attribute if the 
attribute is stable with an assigned value. For example, in 
FIG. 38, the two source attributes corresponding to columns 
A and B, are stable with values. In particular, the CUST_ 
REC attribute has as a value a tuple with first fields being 
namee"John Doe", address="101 Ash, LA", card_coloro 
"gold", and hates_promos?=FALSE. The ACCOUNT_ 
NUMBER attribute has a value of 421135. The cells repre- 
senting these attribute values also di^lay the label "SV" 
indicating that the attributes are stable with an assigned 
value. The remaining ceUs in row 4 display the label "NS", 
indicating that the corresponding attributes are not stable. 
The fifth row of the display displays the states of the 
modules. The three foreign modules (shown in columns C, 
D, and E) are in state ENABLED+READY, a consequence 
of the fact that their enabling conditions are all TRUE and 
their input attributes are stable. The module CALCULArE_ 
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CUST„ VALUE is also in state ENABLED+READY as that led from the display of FIG. 38 to the display of FIG. 

shown in cell 15. This is because its associated enabUng 39. Specifically, the rule represented by cell G6 has become 

condition is TRUE, and by assumption all decision modules C0N1)ITI0N_FALSE as indicated by the symbol 1, and 

begin in state READY. The other decision modules are in the rule represented by cell G8 has become 

state READY, because the attributes used in their enabling 5 CONTRIBUTED_VALUE as indicated by the value -9 and 

conditions arc not yet stable. label C-V Since the NET_PROFIT_SCORE attribute has 

Rows 6, 7, 8, . . . are used to indicate the evaluation status become DISABLED, no further information about the com- 

of computation rules. Accordingly, cells are shown in these putation rules shown in column G need to be computed, 

rows only for decision modules corresponding to columns F, since the attribute will not contribute to the final outcome of 

G, H, 1, and J. The cells in rows 6, 7, 8, ... are called rule lO the workflow execution. 

cells. For each attribute A whose value is computed by a The execution progression has also permitted evaluation 

decision module, there is a oae-tOH3ne correspondence of the computation rule corresponding to cell H7, and hence 

between the computation rules for A and the rule cells in the the evaluation of the LATE_PAYMENTS_SCORE 

column for A. Note that for clarity only the first 5 rule cells attribute. The execution progression has also permitted 

for attribute NET_J*ROFIT_SCORE (column G) are 15 evaluation of the condition of the rule corresponding to cell 

shown, even though FIG. 16 shows this attribute as having 16. 

7 computation rules. The algorithm for maintaining and dynamically updating 

The evaluation status of the computation rules at a point the GUI display as described above is shown in FIGS. 40A 

in the execution is indicated in the corresponding rule cells. and 40B. TTie algorithm contains two main sections. The 

The states of READY and CONDITION_TRUE are indi- 20 Initialization section is used to initialize the display prior to 

cated by labels within the cell. The states of beginning execution of the workflow. The Iteration section 

CONTRIBUTION__COMPUTED and CONTRIBUTED_ is executed when new information is received from the 

VALUE are indicated by placing a value in the cell along execution engine 2812 and the display is to be updated with 

with the label C-V to indicate a state of CONTRIBUTED_ the new information. 

VALUE or the label C-C to indicate a state of 25 We now describe one way that the processing for sup- 

CONTRIBUTION_COMPUTED. The state of porting the GUI could be incorporated into the basic algo- 

C0NDITION„FALSE is indicated by placing the symbol rithm of FIG. 34. Because this algorithm views the execu- 

X, representing a null value, in the cell. tion of decision modules as external "black boxes", the 

In the embodiment described here, it is assumed that illustration here does not include a display of the incremen- 

computation rule conditions and contributions are evaluated 30 tal evaluation of computation rules. The Initialization step of 

eageriy. In FIG. 38, cells G9. H6, H8, 17, and 19 indicate FIG. 40A could be included at the end of part 3406 of FIG. 

that the corresponding rules are in state CONDITION_ 34A. The Iteration phase of FIGS. 40A and 40B could be 

FALSE. All of these rules have conditions based on the card included in section 3414 of FIG. 34B, just after section 

color of the customer, which is known from the value of 3420. In this case, the Iteration phase would be appUed 

attribute CUST_REC. Similarly, cell Hi is in state 35 multiple times, once for each relevant event that occurs 

C0NDITION_TRUE because the condition for the corre- during execution of section 3422. Altematively, the Iteration 

spending rule is CUST_REC.card_color-"gold". phase of FIGS. 40A and 40B could be included (a) into 

However, the contribution for the rule corresponding to cell section 3414 of FIG. 34B just after section 3418 and (b) into 

H7 depends on the ACCOUNT__HISTORY attribute, which section 3422 of FIGS. 34B and 34C just after each occur- 

is not yet stable as indicated by cell D4. In contrast, cells 40 rence of a command that assigns a state value to an attribute 

GIO and 18 are in state CONTRIBUTED_VALUE, because (i.e., a value for a[C] for some attribute C). Based on this 

their corresponding rule conditions are true and the rule description it would be clear to one skilled in the art how to 

contributions depend on no attributes (and hence, on no incorporate processing to support the GUI into the extended 

attributes that are currently unstable). Cell J6 is in state algorithm of FIG. 35, and into algorithms that support 

CONTRIBUTION_COMPUTED because the correspond- 45 execution of DL specifications that are eager with respect to 

ing rule condition depends on a non-stable attribute as the evaluation of compulation rule conditions and/or com- 

indicated by cell J4, but the rule contribution is the constant putation rule terms. 

value "collect". The remaining rule cells are in state As used throughout the description of the algorithm, 

READY, since both their rule conditions and contributions various "indications** are applied to cells. An indication may 

depend on attributes that are currently not stable. 50 be any type of visible indication, such as color, shading, 

FIG. 39 shows an example display screen shot after pattern, outline, icon, or alphanumeric label, which conveys 
several steps have occurred in the execution of the workflow information to a user. Alphanumeric labels are used for the 
and the evaluation of the attributes has progressed. In example screen shots shown in FIGS. 38 and 40. IVrning 
particular, FIG. 39 shows that the attributes RECENT_ now to the algorithm of FIGS. 40A and 40B, in hne 4002 
PURCHASES and ACCOUNT_HISTORY have returned 55 rowsl,2,and3of the display are generated based on the DL 
values as shown in cells D4 and E4 respectively. A value for specification. In section 4004 row 4 of the source attributes 
attribute RECENT__CONTACTS has not yet been received is initialized. If the source attribute has a value, then the 
as indicated by oeU C4. Based on this partial information, it value is inserted in the cell and the attribute_value_ 
has been determined in the execution that the indication is apphed to the cell. If the source attribute is 
CALCULArE_NET_„PROFIT„SCORE module is dis- 60 disabled, then the attribute_disabled ^indication is applied 
abled as indicated by the label DISABLED in cell G5. The to the cell. In section 4006 the cells representing the non- 
associated attribute value cell, G4, now contains the null decision modtiles are initialized by applying a module_ 

symbol 1 and the label "SU" indicating that the attribute uninitialized indication in row 5 and an attribute 

value is stable and undefined. uninitialized ^indication in row 4. In section 4008 the cells 

Note that values for the conditions and contributions of 65 representing the decision modules are initialized by applying 

two additional computation rules of the NET_J*ROFIT_ a module_ready indication in row 5 and an attribute 

SCORE attribute have been obtained during the execution uninitialized ^indication in row 4. In section 4010 the rule 
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cells arc initialized by applying a rulc_rcady_indication to 
the rule cells in rows 6, 7, 8, . . . 

The Iteration section of the algorithm is now described. 
This section is one case statement such that the processing 
to be performed depends on the type of event received from 5 
the execution engine 28 L2. If the event is a non-decision 
module entering state ENABLED, then in section 4012 a 
module_cnabled_indicatioa is appUcd to the appropriate 
cell in row 5 of the display. If the event is a non-decision 
module entering state READY, then in section 4014 a lO 
module_ready_Jodication is applied to the appropriate cell 
in row 5 of the display. If the event is a non-decision module 
entering state READY+ENABLED, then in section 4016 a 
modulc_ready+cnablcd_indi cation is applied to the appro- 
priate cell in row 5 of the display. If the event is a 15 
non-decision module entering state COMPUTED, then in 

section 4018 a module_compul6d indication is apphcd to 

the appropriate cell in row 5 of the display, the computed 
value is displayed in the appropriate cell in row 4 of the 
display, and an attributc_computcd_indication is applied to 20 
the cell in row 4. If the event is a non-decision module 
entering state VALUE, then in section 4020 a module_ 
value_indication is appUed to the appropriate cell in row 5 
of the display, the cell in row 5 is labeled as "value", the 
assigned value is displayed in the appropriate cell in row 4 25 
of the display, and an attribute_value _indication is applied 
to the cell in row 4. If the event is a non-decision module 
entering state DISABLED, then in section 4022 a module_ 
disabled_indication is applied to the appropriate cell in row 
5 of the display, the cell in row 5 is labeled as "disabled", the 30 
J_ symbol is displayed in the appropriate cell in row 4 of the 
display, and an attribute_disabled ^indication is applied to 
the cell in row 4. If the event is a decision module entering 
state ENABLED+READY, then in section 4024 a module_ 
enabled+ready„indication is applied to the appropriate cell 35 
in row 5 of the display and the cell is labeled as "enabled+ 
ready". If the event is a decision module entering state 
COMPUTED, then in section 4026 a module_computed_ 
indication is applied to the appropriate cell in row 5 of the 
display, the ceU in row 5 is labeled as "computed", the 40 
computed value is displayed in the appropriate cell in row 4 
of the display, and an attribute_computed_indication is 
applied to the cell in row 4. If the event is a decision module 
entering state VALUE, then in section 4028 a module_ 
value_indication is applied to the appropriate cell in row 5 45 
of the display, the cell in row 5 is labeled as "value", the 
computed value is displayed in the appropriate cell in row 4 
of the display, and an attribute_value_indication is applied 
to the cell in row 4. If the event is a decision module entering 
state DISABLED, then in section 4030 a module_ 50 
disabled_indication is apphed to the appropriate cell in row 
5 of the display, the cell in row 5 is labeled as "disabled", the 
1 symbol is displayed in the appropriate cell in row 4 of the 
display, and an attribute_disabled_indication is applied to 
the cell in row 4. . 55 

If the event is a computation rule entering state 
CONDITION-TRUE, then in step 4032 a rule_cond_true_ 
indication is applied to the appropriate rule ceU. If the event 
is a computation rule entering state CONTRIBUTION- 
COMPUTED, then in step 4034 the computed value is 60 
displayed in the appropriate rule cell and a rule_ 
contribution„computed_indication is applied to the cell. If 
the event is a computation rule entering state 
CONTRIBUTED-VALUE, then in step 4036 the computed 
value is displayed in the appropriate rule cell and a rule_ 65 
contributed_value_Jndication is applied to the cell. If the 
event is a computation rule entering state CONDITION- 
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FALSE, then in step 4038 the ± symbol is displayed in the 
appropriate rule ccU and a rule_condition_false_indication 
is applied to the ccU. 

The above description described one embodiment of the 
GUI. Those skilled in the art could implement many varia- 
tions of the GUI. Examples of such variations follows. 

1. Different coloring and labeling conventions: Use different 
colors and/or patterns for indicating the state and/or other 
information about computation rules at different points in 
the execution. Use additional or different information in 
the labels for cells, e.g., include a time-stamp for when the 
value for a cell has been computed. 

2. Different execution algorithms: show the progress of 
executions in conjunction with different algorithms for 
executing decision modules. 

3. Different FSAs: The GUI can be used with FSAs for 
computation rules which are different than the FS A shown 
in FIG, 37. 

4. User control over visual layout: Permit the user to hide or 
expose selected columns or rows of the display. Also, 
permit the user to click on cells to display more informa- 
tion about them. For example, clicking on a rule cell could 
result in the display of a pop-up window showing the rule. 
Clicking on a cell in row 2 could result in the display of 
the CPL program specifying the combining policy asso- 
ciated with that cell. 

5. Different visual layout: In FIGS. 38 and 39, attributes are 
positioned along the horizontal axis and rules positioned 
along the vertical axis. Many alternatives are possible. 
Some representative examples include: (a) position 
attributes along the vertical axis and rules along the 
horizontal axis; (b) instead of using a grid paradigm, show 
decision modules as hexagons as in FIG. 5 and show rule 
status for a given attribute using a column or row of cells; 
(c) same as (b) but display the cells for rules in a 
tree-based or other structure that reflects the kinds of 
contributions different rules might make. 

6. Use in conjunction with systems not based on DL 
specifications, including systems specified using, for 
example, flowcharts, procedural languages, or scripting 
languages. 

7. Batch display: The example described above iUustrates 
how to display the execution of a single workflow 
instance. The visual paradigm can be used to display the 
result of executions of a set of workflow instances. For 
example, the color of a rule cell might be based on the 
percentage of executions for which the condition of the 
corresponding rule was true. Rule cells might be labeled 
with an aggregate value (e.g., an average) indicating the 
family of contributions made by the rule in different 
executions. 

8. Permit backtracking: The example assuimed that the 
sequence of displays produced corresponded to an actual 
or hypothetical execution of the workflow. It is also 
possible to permit a user to halt the execution, and modify 
it by replacing the values of source or non-decisioo 
attributes. 

9. Highhght data dependencies between cells: For example, 
the interface could permit the user to click on rule cells in 
order to display relationships between attributes and rules, 
e.g., what attributes does a rule condition depend on, or 
what attributes does a rule contribution depend on. 

10. Incorporate general modules: The example assumed that 
each module produced exactly one output attribute. The 
GUI can be used in contexts where modules produce more 
than one attribute. This could be accomplished, for 
example, by permitting cells in the first, second and fifth 
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rows to sp^ a number of coliunns equaling the number of 
output attributes of a given module. (This was done for 
the source attributes, in columns A, B of row 1 in FIGS. 
38 and 39). 

The foregoing Detailed Description is to be understood as 
being in every respect illustrative and exemplary, but not 
restrictive, and the scope of the invention disclosed herein is 
not to be determined £rom the Detailed Description, but 
rather firom the claims as interpreted according to the full 
breadth permitted by the patent laws. It is to be understood 
that the embodiments shown and described herein are only 
illustrative of the principles of the present invention and that 
various modifications may be implemented by those skilled 
in the art without departing from the scope and spirit of the 
invention. 

We claim: 

1. A computer readable medium storing a program speci- 
fication defining steps to be performed by a programmed 
computer, said program specification defining: 

at least one data item; 

a plurality of computation rules associated with said at 
least one data item defining values to be contributed to 
said data item; 

at least one combining policy associated with said at least 
one data item defining a manner in which said contrib- 
uted values are combined in order to assign a final value 
to said at least one data item; and 

a step to assign said final value to said at least one data 
item based on said at least one combining policy. 

2. The computer readable medium of claim 1 wherein said 
program specification further defines: 

a condition and a term associated with each of said 
computation rules wherein said term defines a value to 
be contributed if said condition is satisfied; and 

a step to evaluate said computation rules associated with 
said at least one data item by performing the following 
for each computation rule associated with said at least 
one data item: 

a step to evaluate said condition; and 

a step to contribute said term to said at least one data 
item when said condition is satisfied, wherein said 
term is not contributed to said at least one data item 
when said condition is not satisfied. 

3. The computer readable medium of claim 1 wherein said 
at least one combining policy is further defined by a com- 
bining policy language program. 

4. The computer readable medium of claim 1 wherein said 
at least one combining policy is further defined by a com- 
bining policy language function which represents a combin- 
ing poUcy language program. 

5. A computer system comprising: 

a memory storing a program specification, said program 
specification defining: 
at least one data item; 

a plurality of computation rules associated with said at 
least one data item defining values to be contributed 
to said data item; 

at least one combining policy associated with said at 
least one data item defining a manner in which said 
contributed values are combined in order to assign a 
final value to said at least one data item; and 

a step to assign said final value to said at least one data 
item based on said at least one combining policy; and 
a processor for evaluating data items based on said 

program specification. 

6. The computer system of claim 5 wherein said program 
specification further defines: 



a condition and a term associated with each of said 
computation rules wherein said term defines a value to 
be contributed if said condition is satisfied; and 
a step to evaluate said computation rules associated with 
said at least one data item by performing the following 
for each computation rule associated with said at least 
one data item: 

a step to evaluate said condition; and 
a step to contribute said term to said at least one data item 
when said condition is satisfied, wherein said term is 
not contributed to said at least one data item when said 
condition is not satisfied. 

7. The computer system of claim 5 wherein said program 
specification further defines a combining policy language 
program. 

8. The computer system of claim 5 wherein said program 
specification further defines a combining policy language 
function which represents a combining policy language 
program. 

9. A method comprising the steps of: 
providing at least one data item; 

providing a plurality of computation rules associated with 
said at least one data item defining values to be con- 
tributed to said data item; 
providing at least one combining policy associated with 
said at least one data item defining a manner in which 
said contributed values are combined in order to assign 
a final value to said at least one data item; and 
assigning said final value to said at least one data item 
based on said at least one combining policy. 

10. The method of claim 9 wherein: 
the step of providing at least one combining poUcy further 

comprises the step of providing a combining policy 
comprising the steps of: 

determining which value of the contributed values is 
highest; and 

assigning the highest contributed value to said at least 
one data item. 

11. The method of claim 9 wherein: 
the step of providing at least one combining policy further 

comprises the step of providing a combining policy 
comprising the steps of: 
summing values for the contributed values; and 
assigning the sum to the at least one data item. 

12. The method of claim 9 further comprising the steps of: 
providing a condition and a term associated with each of 

said computation mles wherein said term defines a 
value to be contributed if said condition is satisfied; 
evaluating said computation rules associated with said at 
least one data item by performing the following steps 
for each computation rule associated with said at least 
one data item: 

evaluating said condition; and 
contributing said term to said at least one data item 
when said condition is satisfied, wherein said term is 
not contributed to said at least one data item when 
said condition is not satisfied. 

13. The method of claim 9 wherein said at least one 
60 combining policy is further defined by a combining policy 

language program. 

14. The method of claim 9 wherein said at least one 
combining poficy is further defined by a combining policy 
language function which represents a combining policy 

65 language program. 
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